CSPM to CSP₀ compiler

(from [2b108c39f9179982b3d2447a980928aeb81e99d5]) Initial Haskell CSPM implementation

This is an initial patch implementing the CSPM language in Haskell. I've chosen Haskell since, like CSPM, it's a lazy functional language. This means we don't have to “implement” any of the functional features of CSPM; rather, we can just call the appropriate Haskell functions.

This patch includes a basic implementation of the simple non-process expressions in CSPM. It does not yet include variable references, ‘let’ bindings, or functions, since they'll all require static-scoped environments. There is a basic test suite, based on QuickCheck. I also still need to wrap everything up in a Cabal package.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [6ee10a95b2524c1f021968f4e51d028c206df988]) Initial support for CSP₀ scripts

This patch introduces support for CSP₀ scripts. It has functions for creating CSP₀ statements and scripts, but there's no functionality yet for translating CSPM into CSP₀.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [893bd7eea2410221f85d076815f92f677d8c72ae]) Binding and evaluation now take place in a monad

Once we add process terms to the CSPM language, we'll need a State monad to bind and evaluate them, since we'll need to generate new, unique process names during evaluation. This patch refactors the existing binding and evaluation code to use a State monad. Right now, the state is empty, but once we introduce processes, it will contain the list of used process names.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [06628c3b6114894c0d8cac5a3f5b327a0e922acd]) Evaluate process expressions

This patch introduces initial support for evaluating process expressions into the equivalent CSP₀ scripts. There are still several important features to implement. Process names are based on the outermost named process term. Currently, these can only be introduced by a let statement. Functions that return processes don't completely work yet, since we'll need to encode the parameters of the function into the names of the processes that are generated by the function application. Finally, there isn't yet a good test suite for these new features.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [7ed2249fe1b6063e163cc121b3289f37bfdf5969]) Binding and evaluation now take place in a monad

Once we add process terms to the CSPM language, we'll need a State monad to bind and evaluate them, since we'll need to generate new, unique process names during evaluation. This patch refactors the existing binding and evaluation code to use a State monad. Right now, the state is empty, but once we introduce processes, it will contain the list of used process names.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [6257983d18e9ad718d8dbc9d7e528bda55098fcd]) Evaluate process expressions

This patch introduces initial support for evaluating process expressions into the equivalent CSP₀ scripts. There are still several important features to implement. Process names are based on the outermost named process term. Currently, these can only be introduced by a let statement. Functions that return processes don't completely work yet, since we'll need to encode the parameters of the function into the names of the processes that are generated by the function application. Finally, there isn't yet a good test suite for these new features.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [d67f471b5af179c9f0d865c425c0542dbe3fa9cd]) Adding predefined SKIP and STOP processes

This patch introduces CSPM keywords for the predefined SKIP and STOP processes.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [aa9d7b026e4d5b6c7d06ca08a849c33b0c680888]) Distinct process names for each application of a function

Before, a process created by a function application would get its name based on the context in which the lambda was defined. This meant that if you called a function many times, each with different values for its parameters, you'd only get a single process definition in the output script. Ideally, we'd add to the process name some representation of the values that the function was called with. Unfortunately, that's not possible with the current design, since the parameters to a function are lazy. We bind the function application (thereby creating its process name) before evaluating the lambda's body, and we cannot evaluate any of the parameters before evaluating the lambda's body. Thus, we cannot use the parameter values to calculate the process name.

We could probably reorganize things to get around this, but for now, we just keep track of a global counter of function applications, and append this counter to the process name created for any application. This means that if we apply a function many times with the same value, we will get distinct processes for each one.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [449a427b153538a6bd72d9128d1f3fb9471d19ff]) Initial support for CSP₀ scripts

This patch introduces support for CSP₀ scripts. It has functions for creating CSP₀ statements and scripts, but there's no functionality yet for translating CSPM into CSP₀.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...

(from [449a427b153538a6bd72d9128d1f3fb9471d19ff]) Initial support for CSP₀ scripts

This patch introduces support for CSP₀ scripts. It has functions for creating CSP₀ statements and scripts, but there's no functionality yet for translating CSPM into CSP₀.

Lighthouse: [#2 CSPM to CSP₀ compiler] http://github.com/dcreager/hst/c...