20 Feb 2012 00:31
On LtU: Discussion of Erlang-like vs E-like concurrency model
_______________________________________________ e-lang mailing list e-lang@... http://www.eros-os.org/mailman/listinfo/e-lang
20 Feb 2012 04:32
Re: [friam] On LtU: Discussion of Erlang-like vs E-like concurrency model
On 2/19/12 at 15:31, erights <at> google.com (Mark S. Miller) wrote: >http://lambda-the-ultimate.org/node/4453 Some of the key paragraphs were incomprehensible to me because of errors in English composition: >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 (408)356-8506 |not an add-on feature. - Attr-| 16345 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos, CA 95032 _______________________________________________ e-lang mailing list e-lang <at> mail.eros-os.org http://www.eros-os.org/mailman/listinfo/e-lang
23 Feb 2012 17:52
Data flow (was: Re: On LtU: Discussion of Erlang-like vs E-like concurrency model)
On 2/19/2012 3:31 PM, Mark S. Miller wrote: > 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
23 Feb 2012 20:45
Re: Data flow
On 23/02/12 17:52, Jed Donnelley wrote: > On 2/19/2012 3:31 PM, Mark S. Miller wrote: >> 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
12 Mar 2012 06:23
Re: Data flow
On 2/23/2012 11:45 AM, Peter Van Roy wrote: > On 23/02/12 17:52, Jed Donnelley wrote: >> On 2/19/2012 3:31 PM, Mark S. Miller wrote: >>> 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 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/
RSS Feed