Scheme is a relatively small language with strong ties to the lambda calculus, an algebra developed by Alonzo Church for describing the application of functions to their arguments.
occam is a small language with strong ties to CSP (communicating sequential processes), an algebra originally devised by Professor Sir Tony Hoare for describing synchronous message passing in concurrent systems.
A small piece of occam that adds two numbers might look like
PROC a()
INT x, y, z:
SEQ
x := 3
y := 5
z := x + y
:
|
This declares three variables, and then (in sequence) sets x to 3, y to 5, and then z to the sum of x and y.
Slightly more interesting, this bit of occam doubles the numbers 0 through 10,000 in parallel:
PROC maniac(VAL INT x)
INT tmp:
SEQ
tmp := x * x
:
PROC main()
PAR i = 0 FOR 10000
maniac(i)
:
|
The procedure main() says to create 10,000 processes in parallel (PAR), and each one should call the procedure maniac() on the value stored at location i.
Our goal is to have a working occam (well, ETC—the assembly language of the transputer) interpreter written in ANSI C. We’ve chosen to implement the interpreter in Scheme first. First, this prevents us from reusing code in our first attempt in our actual implementation. Second, the semantics of the interpreter can be kept clear through the judicious use of macros and the absence of memory management and other low-level concerns. Third, when we complete the rewrite into C, we will be able to validate one against the other, as well as against KRoC, the local occam compiler.
Currently, we can execute all of the above code (when compiled to ETC) correctly.
For now, I’ll leave the questions of why? and how does it tie into your research? open.
Cool. I’ve had “ETC virtual machine for occam” on my ideas list for a while, and it’s nice to see that I’m not the only one who thinks it’d be a neat idea.
The only downside I can see is that it’d give CO516 students less incentive to learn Unix…