[e-lang] On LtU: Discussion of Erlang-like vs E-like concurrency model

[Mark S. Miller]

http://lambda-the-ultimate.org/node/4453

[Bill Frantz]

Post by Mark S. Miller
http://lambda-the-ultimate.org/node/4453

Some of the key paragraphs were incomprehensible to me because

Post by Mark S. Miller
Note that the classical actor model provides only two of these dimensions: 1*3. There is notion of step and there is notion process (actor). And there every even is processed in the single step.
Erlang truthfully implement this model. And it also assumes single step even processing. There is also no work-based decomposition. The work dimension is lost from Erlang. It is also lost from all Erlang-style implementation of actor model.
The proof is quite simple. It is not possible to esaly apply functional composition operators to Erlang actors. And it is possible to specify which events actor receives, but is not hard to specify specify which are directly or indirectly produced by the actor. So it is asynchronous version of “go to” mess of synchronous code.

I assume that every use of the word "even" should be read as "event".

I assume that "esaly" should be "easily".

The second to last sentence, starting, "And it is possible to
specify..." completely eludes me.

If I knew the LtU jargon better, I might be able to make a stab
at parsing that sentence.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz |Security, like correctness, is| Periwinkle
[phone] |not an add-on feature. - Attr-| 16345
Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos,
CA 95032

[Jed Donnelley]

Post by Mark S. Miller
http://lambda-the-ultimate.org/node/4453

Hmm.. As I think you know I'm a fan of data flow programming - in
hardware and languages. Data flow programming is natively asynchronous
but also timing independent. Still, I'm not clear how it fits with the
OO scheme.

--Jed

[Peter Van Roy]

Post by Jed Donnelley

Post by Mark S. Miller
http://lambda-the-ultimate.org/node/4453

Hmm.. As I think you know I'm a fan of data flow programming - in
hardware and languages. Data flow programming is natively asynchronous
but also timing independent. Still, I'm not clear how it fits with the
OO scheme.
--Jed

The Ozma language extends Scala with declarative dataflow,
and fits it very nicely with objects. It's explained here:
http://www.info.ucl.ac.be/~pvr/QCon2011PVR.pdf

Peter

[Jed Donnelley]

Post by Peter Van Roy

Post by Jed Donnelley

Post by Mark S. Miller
http://lambda-the-ultimate.org/node/4453

Hmm.. As I think you know I'm a fan of data flow programming - in
hardware and languages. Data flow programming is natively asynchronous
but also timing independent. Still, I'm not clear how it fits with the
OO scheme.
--Jed

The Ozma language extends Scala with declarative dataflow,
http://www.info.ucl.ac.be/~pvr/QCon2011PVR.pdf
Peter

Hey Peter. Thanks for the note above. Sorry to take so long to notice it.
I'm not particularly active on the e-lang list.

I started going through the above presentation and find it interesting to
see how a modern effort to incorporate dataflow is working. I find it
quite interesting to see the reference to val (I worked at LLNL while
val was under development. I also interacted some with Jack Dennis
in the earlier days).

I wonder if you might be able to give me some information that would
perk my interest more or less:

I'm particularly interested in any programming language that supports
data flow and could in principle run on native data flow hardware - which
I happen to have some simulations of. This hardware has no random
access memory. Programs are more like volume (2d or 3d) consuming
data flow modules, building up bigger ones from smaller ones.

Any thought on whether Scala might be able to be adapted to compile
to such an architecture? Does it require random access memory/arrays?

Thanks for any time to respond - no hurry of course.

--Jed

http://www.webstart.com/jed/