Lambda the Ultimate

I am looking for feedback about the following programming model (more details are available on my blog).

This is a simple transactional programming model where the code is always executed in the context of a transaction. Transactions are executed in complete isolation (all variables are versioned) from other transactions. The effect of a write operation is only visible after a transaction has committed, i.e. it can only be observed from within another transaction that was started after the transaction has committed its writes. The effect of modifying a variable has no observable effect inside the transaction itself, it will become visible only after the transaction has committed. Because of this delayed mutability I call my variables semi-mutable.

Validation at commit time guarantees consistency by verifying that the reads at commit time return the same result as during the execution of the transaction. Read-only transactions always commit (well there is nothing to commit...), write-only transactions always commit too (there is nothing to validate...) New versions are created when write operations are committed.

Spurious conflicts are much reduced or sometimes entirely avoided by leveraging as much as possible the semantics of the variables, for example counters can only be incremented or decremented rather than being read from and assigned to; they also support e.g. isGreaterThan methods. Writes are either merged (e.g. set.Add) or the last write wins (e.g. map.Set). Transactions are not automatically re-executed in case of conflicts.

Multiple threads running concurrently within a single transaction can be either merged or joined. Merging will combine the write operations if they commute, joining will append the write operations of the joining thread (last-write wins).

IO operations are also supported. External reads can be either checked (read operation is re-executed during validation) or unchecked (read operation is not re-executed during validation). External writes are only ever executed if the validation phase succeeds.

A contiguous transaction sees the system in the state a (parent) transaction put it in. Notification transactions are contiguous transactions that contain a reference to the writes performed by the parent transaction.

Transaction-local immutable (mutable could also be supported) variables are supported.

Overall the level of immutability of the state of the system within a transaction is reminiscent of pure functional programming. The state of the system mutates only when a transaction commits but this mutation is not observable by any running transaction. I am tentatively calling the resulting programming model Piecewise Functional Programming.

I am also looking at combining join-calculus with this model in a new language or by adapting an existing one. In particular I am wondering how to best express the commit operation in a language in which all code is executed in the context of a transaction. Most language constructs are based on some form of scope and their compositions, while the commit operation is more of a barrier which defines the progress of time.

Dear all,

The virtual machine of the Mozart system is in dire need of a refresh! It was originally designed in the early 1990s (twenty years ago!) and is now showing its age. We are working on a new virtual machine that is ready for the future. But some of the issues are still not clear, in particular how to represent the data. Yves Jaradin has prepared a detailed discussion of the issues.

We would like to ask advice from the experts on LtU. What is the best way to write a virtual machine today? Is it possible to be simple and still efficient? Please let us know what you think.

- Peter Van Roy and the Mozart development team

i'll be posting this elsewhere so apologies if you see it there before you see it here. this is the first place i'm posting, tho. :-)

the programming language Shen has been released:

Shen 1.7 is a portable release of the Qi II programming language designed to run under a reduced Lisp and a $free license. The first release of Shen 1.7 (under CLisp) is now available as a self-extracting installation under Windows, Linux and OS X. To read about the Shen project designed to unify the tongues of Lisp read here.