The Transterpreter Project

Concurrency, everywhere.

Concurrency for fun and ...

I'll settle for fun.

For the last year, Christian and I have been working on revitalizing an old, little language called occam. Where Scheme is tightly coupled to the lambda calculus, occam is a concise expression of the CSP calculus. Up until recently, occam was only "alive" on Linux/x86. With our work, we've brought occam to Mac OS X, Windows, Linux (all flavors), and the LEGO Mindstorms. I've mentioned it afewtimes on my own weblog; perhaps we should start making a concerted effort to go into some more detail.

What does occam look like? occam is a language of processes; everything, in fact, is a process. These processes are incredibly light-weight, and communicate with each-other via channels (a la Hoare's Communicating Sequential Processes algebra). How about a simple example: producer-consumer, perhaps?

1 PROC producer(CHAN BYTE ch)
3     ch ! 'x'
4 :

This process does nothing but emit an 'x' on the channel ch. Because occam channels are not asynchronous by nature, the process blocks on the send down the channel ch (line 3) until someone performs a read.

A consumer of 'x's might look like

1 PROC consumer(CHAN BYTE ch, CHAN BYTE scr)
2   BYTE tmp:
4     SEQ
5       tmp ? ch
6       scr ! tmp
7 :

The consumer process reads a byte from ch into a locally declared variable (line 5) of type BYTE, and outputs the value received to the screen (line 6).

Of course, these processes are floating in the void. We need one more process that spawns both processes in parallel:

1 PROC main(CHAN BYTE kyb, scr, err)
2   CHAN BYTE c:
3   PAR
4     producer( c )
5     consumer( c , scr)
6 :

This main process is special in that it binds three top-level, external channels that connect to stdin, stdout, and stderr (these are implementation dependent); commonly, these are the keyboard, screen, and error port (line 1). The two processes, producer and consumer are launched in parallel (lines 3,4, and 5), and then the process main exits. PAR, if it isn't obvious, is a process, too; everything indented under it is executed in parallel.

That's it. Having never seen the language before coming to Kent, I was impressed with how simple and clean it is in execution; it's a shame that it "died", so to speak. We've had good experiences working with occam on the LEGO Mindstorms, and look forward to presenting our work and releasing the software at SIGCSE next month.

(For the Schemers in the house, you may take a look at a previous post where I was playing with MzScheme's ConcurrentML library and a quickly hacked together s-expression-based syntax for occam-y constructs.)

Interested in playing with occam?

We've built a few things you might enjoy:

  1. We've co-opted JEdit as an IDE. On Windows or the Mac, you can write and execute occam programs in the IDE.
  2. From the JEdit IDE, you can also execute your programs on the LEGO Mindstorms. Currently, we only have this working on Windows machines.
We're finalizing installers and getting ready for SIGCSE 2005; if you'd like to be informed when we release, and be kept up-to-date on updates, drop a note to matt at, and we'll add you to... well, we'll set up a mailing list.


  • Posted: January 19, 2005
  • Author: Matthew Jadud
  • Comments: None
  • Tags: None