[concurrency-interest] thoughts about stackless languages?

Joe Bowbeer joe.bowbeer at gmail.com
Sun Jul 16 12:39:48 EDT 2006


On 7/16/06, Peter Veentjer <alarmnummer at gmail.com> wrote:
> I was reading an article about stackless python. A stackless language
> should be better scalable, more performant and more intuitive than the
> classic multithreaded approach. What are the opinions about adding
> stackless functionality to the java vm? Is it possible? Is it
> desirable? Is it overrated?
>

Without a stack, flow of control is based on continuation passing style?

http://en.wikipedia.org/wiki/Continuation_passing_style

I think the "lazy" keyword in Oz is interesting, and its
implementation could be based on continuations.

"lazy" is covered in this short presentation on the design of Oz:

http://www.info.ucl.ac.be/~pvr/ircamTalk2006.pdf

It was interesting to me that mutable state and OO weren't mentioned
at all until the very end of the slides, and then were only mentioned
in passing (because, he claimed, mutable state is only needed for
modularity and none of the examples were big enough to need it).

Oz looks like fun.  I'd like to see it running on the JVM.

I saw this catchy title among the Oz papers, and was alarmed to read
that Peter Van Roy was discounting what I always considered to be a
sage verdict from Jim Waldo, et al:

Convergence in Language Design:
A Case of Lightning Striking Four Times in the Same Place

>From http://www.info.ucl.ac.be/~pvr/flopsPVRarticle.pdf

4 Network-Transparent Distributed Programming

This project was motivated by the desire to simplify distributed
programming by making a practical system that is both network
transparent and network aware. [...]

Some researchers have maintained that this cannot work; that network
transparency cannot be made practical, see, e.g., Waldo et al [28].
They cite four reasons: pointer arithmetic, partial failure, latency,
and concurrency. The first reason (pointer arithmetic) disappears if
the language has an abstract store. The second reason (partial
failure) requires a reflective fault model, which we designed for the
Distributed Oz language. The final two reasons (latency and
concurrency) lead to a layered language design. Let us examine each of
these reasons. Latency is a problem if the language relies primarily
on synchronized operations. In the terminology of Cardelli, latency is
a network awareness issue. The solution is that the language must make
asynchronous programming both simple and efficient.

--Joe

PS -

Scala is a language with an efficient "actor" implementation that does
run on the JVM.

http://en.wikipedia.org/wiki/Scala_programming_language


More information about the Concurrency-interest mailing list