Lambda the Ultimate

There is a lot of discussion on LtU, past and present, about the advantage that a pure functional language has w.r.t. concurrency, but for several reasons that I won't go into here, I am designing a non-pure multi-paradigm language called Virgil. Originally I focused on making the language usable for microcontroller programming, which is an interrupt model that I managed to accomodate without introducing any constructs for concurrency. Virgil had no synchronized { ... } blocks, no atomic { ... } regions, and no event system. Instead, the programmer could attach methods to what I called entrypoints which represented where control would transfer to in the event of an interrupt (or nested interrupt). Thus a one stack model would suffice. Managing mutual exclusion was done manually by manipulating hardware state.

But now I want to make Virgil into a larger, more complete language. I have been redesigning the syntax a bit and building a new compiler in the language itself, bootstrapping off the earlier compiler's interpreter which I wrote in Java.

I am faced with the question of what concurrency constructs to introduce, and how they can express these kinds of concurrency:

- Interrupts: e.g. in a one-stack interrupt-driven microcontroller
- Events: e.g. in a GUI framework
- Async IO: e.g. in a high-performance IO subsystem for a webserver
- Threading: e.g. multiple concurrent threads of computation for multicore
- (others)

It seems that other languages have made the leap from a single-thread, non-current model to a different model either through the introduction of monitors and thread (e.g. Java), a threading library (e.g. C), atomic regions (e.g. nesC), or other language mechanisms.

I'm curious if people have advice in this direction.