Lambda the Ultimate

I am not an expert on concurrent languages, but is Concurrent ML really such a noteworthy language in this area that is deserves mention in their bibliography?
On the CML web page http://cml.cs.uchicago.edu/doc.html I find no academic publications.

There are actually quite a few publications about Concurrent ML. I don't know why they're not listed on the CML page.

I believe CML was the first concurrent functional language. Perhaps even the first "production language" period to embed concurrency constructs. I'd definitely say its noteworthy.

Is CML going from 1986-88 as Erlang is? But don't wory, Erlang is not mentioned in this article too ;-) They reinvent wheel and worse they looks like Sumerian don't exists.

Several "production languages" with embedded (message-passing) concurrency constructs predate CML by a number of years. The ones that immediately leap to mind are:

• Erlang (initial experiments in 1987, production use in 1988)
• occam (initial release in 1983)
• Ada (international standard in 1983)

I probably should have been more precise in my wording. CML was the first statically typed language to include flexible concurrency constructs that I'm aware of. Neither Erlang nor Occam are statically typed, though they provide flexible concurrency. Ada is statically typed, but it's rendezvous model has long been considered too limited.

I'm fairly sure that occam has been statically typed since at least version 2 (released in 1986), in addition to statically checking various "parallel usage rules" on channels and variables. Occam 1 may well have been statically typed as well, although the only types it supported were machine words and arrays.

[Edit: Just to be clear, I think that there's no doubt that CML provides some substantially more powerful abstractions than occam. On the other hand, I think occam was, in its day, probably much more widely used in industry than CML.]

Hmm, for some reason I was under the impression that Occam was dynamically typed. I stand corrected!

No worries. It seems to be a common mistake. I'm not sure why. If anything, occam was the antithesis of "dynamic" - it didn't even support dynamically-sized arrays (let alone dynamic process networks) until Fred Barnes and Peter Welch added them to occam-pi. Classical occam was used a lot in the embedded domain, and static allocation was considered a good thing from the perspective of predictability.

I have a great deal of respect for John Reppy's work, which I first encountered in his 1988 paper on synchronous operations as first-class values. I used to include a lecture or two on this paper when teaching ML. Re-reading this paper, I realize that CML choose and Erasmus select are very similar. However, other languages (CSP, occam, Joyce, Ada, ...) have used similar constructs.

Threads in CML are first-class continuations; Erasmus threads are not.

I have been looking for Joyce implementation, (As described in "A Programming Language for Distributed Systems"). Any idea where I can find it? (Or who might be working with it now.)

Any information at all would be appreciated.

author apparently passed away [LtU].

a message from the author mentioning occam and joyce.

a related language of his, super pascal, is apparently still available.

but i didn't stumble across joyce itself.

 author apparently passed away [LtU].

I have been reading his papers.

Trying to compile superpascal, but not successful yet (seems to depend on extensions by SPARCompiler for pascal which seems to have been discontinued by sun.)

Yes, CML is noteworthy and influential. The foldoc page has a nice summary of its features. From those features, one can guess why concurrency implementations in e.g. PLT Scheme and Scheme 48 were based on it.

CML is a great language, but it's hardly the only (or the most popular) language based on message-passing concurrency. It's a shame that their bibliography left out CML, but it also left out a lot of other concurrent languages (Alef, Limbo, Erlang, E, SALSA, etc.). What they did cover are the languages that seem most closely related to the goals of Erasmus.

Regarding novelty, although I haven't looked at Erasmus deeply yet, I believe following are probably the key features:

• Processes as the fundamental building block of programs, as opposed to using functions or objects (this is similar to occam, but embedded with a language that appears to have a richer feature-set than occam).
• Protocols definitions that act like types for channels, but define message sequencing, and may include pre- and post-conditions. These sound a little like the formal dialogs used in Active C#, but I don't think that dialogs support an inheritance hierarchy the way Erasmus' protocols do.

However, as the Erasmus group freely admits, pieces of what they're doing has been done before in various languages (including CML). The main goal of the Erasmus project seems to be to find a way to integrate all of the good ideas from earlier languages into a coherent whole.

Thanks for posting this Chris - I hadn't come across Erasmus before, but it sounds like an interesting project. I'm looking forward to reading more about it.

We do not cite Erlang in the report that Chris linked. We do cite it in the reports of April 2007 and September 2007. The success of Erlang is very encouraging because it demonstrates the feasibility of process-oriented languages. Unlike Erlang and CML, however, Erasmus is not a functional language. I would certainly not deny that "more than half of this article is many years used and verified in practice" — we looked for the good stuff before we started and are still learning!

Forget functions; forget objects; think processes

Isn't this the same thing the Erlang guys proselytized using the term concurrency oriented programming (COP)?

According to Armstrong's History of Erlang, Erlang started as an "experiment in adding concurrency to Prolog". A "philosophy" developed within the Erlang group, and it is now called COP. COP has been explained in various ways, one of which is "a kind of hybrid language between concurrent languages and functional languages", which is why Erlang is often referred to as a "functional language".

Our ideas certainly have a lot in common with COP. We make no claim to be functional. However, we are finding that there are advantages to reducing the amount of state in processes, which suggests a possible convergence with Erlang.

Yes, both models are exactly the same: processes sending messages. Analogously, Smalltalk and Java are exactly the same: instances of a hierarchy of classes invoking one another's methods.

There are a lot of different models that can be summarized as "sending messages from one part of a program to another". These models differ in exactly how the messages are passed, and what the "parts of the program" look like. To me, the most immediate differences between what Erasmus is doing and the classical Hewitt/Agha Actor model are:

1. Communication in Erasmus is fundamentally based on rendezvous, while Actors fundamentally communicate asynchronously. There has been a lot of argument about which makes the most sense as a "primitive" of communication. Both approaches have been used successfully in industrial applications as well as academia.
2. Actors have names, and communicate by sending messages to named entities. Erasmus processes appear to be anonymous, in the sense that communication between processes is via ports rather than by sending to named Actors. It's possible to debate endlessly about the pros and cons of port/channel-based communications versus address-based communications. One advantage of port-based comms is that it makes it easier to achieve compositionality of processes, which would provide support for the scale-free assembly of systems that the Erasmus group seems to be shooting for.

The use of port/channel-based rendezvous communications makes Erasmus more similar to something like CSP or the pi-calculus than to the Actor model.

It's possible to debate endlessly about the pros and cons of port/channel-based communications versus address-based communications.

The two approaches may have the same network-level semantics, but they don't have the same security properties. Protected ports (aka capabilities) are fundamentally more secure than addresses. Unless you spawn an agent for every channel, in which case addresses and ports are now synonymous.

Aren't addresses forgeable were channels not? I don't see how we can make adresses and ports equivalent if we can forge an arbitrary address and therefore gain access to the process behind it but ports must be passed explicitly.

I have thought of that, but I would imagine an address is not forgeable within a language. Even if it is, we could make them capabilities by making the addresses sparse (ie. unguessable).

We can make capabilities out of them, but if we can forge addresses then there's this hole where addresses aren't used as capabilities, similar to OO languages that can be used to write programs using caps but basically fail at it because the backdoor is there and widely used in the base libraries. I agree that we can make forgeable addresses unguessable (e.g. the whole safe URI concept) but this is an encoding and the properties of the encoding don't hold outside it (i.e. in the host language), so we can only say that sparse unguessable addresses are equivalent to capabilities, but if the program uses something else all the bets are off. In a capability environment we can look at the port definition and know for sure what capabilities the program attached to it has, but sparse unguessable addresses don't have the same property.

On an open network, sparse capabilities are all we have. It's not clear to me that addresses are forgeable though.

Thank you for the clarification! One reason for preferring ports is that there is less coupling between components. A disadvantage is that components must be explicitly linked: the 'plumbing problem'. We have various plans for dealing with the plumbing problem, notably the distinction between 'cells' that provide structuring and 'processes' that perform actions.

Security will be very important for future concurrent and distributed systems. In IBM's Hermes, a process starts out with one port, through which it receives all of the capabilities it needs to do its job, including ports linking it to other processes. Erasmus can do this too, since ports are first-class, and this approach may turn out to be the basis of our security model.