[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrent programming coming to JavaScript
Dear list,
Currently I'm reading "An Algebraic Theory of Actors and its Application
to a Simple Object-Based Language" by Agha and Thati*. Second page
states the difference with pi-calculus: asynchronous vs synchronous, and
unique and everlasting (actor) names vs non-unique and disappearing
(process) names. It describes the actor model in terms of restrictions
upon pi-calculus.
The "receptionist interface" is an interface that defines visibility to
the outside world. Uniqueness is defined w.r.t. those interfaces. IMHO
there are some (operational) points neglected:
* The process of becoming "globally visible" (becoming a
receptionist);
* A hierarchy of scopes (Kell calculus);
* The process with which unique names are generated;
* The process in which known actor names are retrieved;
There is a discoupling between actor name and actor behaviour. Actor
name cannot disappear, but its behaviour can change totally.
Anyway, current programming object-based languages seem pretty good
approximated? But are they not primitive? What about:
* The policy for visibility/scope. Are there no alternatives?
* The policy for interprocess communication.
* The policy for encapsulation (grouping does not necessarily
involve visibility parameters).
I consider the idea of (reconfigurable) channels [Arbab], as very
valuable. But it's very important not to loose certain abstractions. And
even more important: create a reconfigurable, dynamic communication
structure that will be adopted by the programming community rather than
the other way around.
Kind regards,
Anne
PS: I should be more humble ;-) I only know of CCS, CSP, Actor models,
PI-calculus, etc. since new year.
* download: http://yangtze.cs.uiuc.edu/~thati/festschrift.pdf
On Sat, 2007-02-24 at 16:06 -0700, Allan McInnes wrote:
> I know from online exchanges with Carl Hewitt (the driving force behind much the
> Actor model work) that he was aware of the work being done on CCS/CSP.
> Similarly, Will Clinger's PhD thesis on Actor model semantics mentions the
> original CACM paper on CSP. Going the other way, I gather that Robin Milner (at
> least) was aware of what Hewitt was up to as well, since Milner's Turing Award
> lecture references the Actor model as part of the inspiration for the
> pi-calculus.
>
> Despite the fact that both groups seem to have been at least somewhat aware
> of the other, for some reason the two communities appear to have grown quite
> separately. Part of that can perhaps be attributed to some fundamental
> differences of opinion over appropriate primitives: my impression is that
> Hewitt strongly favored named agents with asynchronous communications, while
> Milner and Hoare were more in favour of anonymous agents with rendezvous
> communications - the latter lending itself much more easily to algebraic
> analysis. The result was that theoretical work in one community was less
> likely to be applicable to problems faced by the other community.
>
> That said, I agree with Barry that the CPA community and the Actor community
> definitely share common aspirations and common concerns. It'd be good to see
> greater cooperation between the two groups in advocating share-nothing,
> message-passing concurrency.
>
> Allan
>
>
>
> Quoting Barry Cook <Barry@xxxxxxxxxxxx>:
>
> > Allan gives a very nice summary of the differences between the Actor model
> > and CSP - but there are also very many things in common - or at least common
> > desires. I found the article in http://en.wikipedia.org/wiki/Actor_model
> > VERY thought provoking.
> >
> > Maybe we are less out-on-a-limb than we think (?)
> >
> > I need to follow-up some of the leads from this article, and other places.
> > The Actor model has not been much mentioned in WoTUG (CPA) [as far as I can
> > remember] - is there a good reason for this or should we be looking at it
> > more seriously?
> >
> > Barry.
> >
> > Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
> > CTO,
> > 4Links Limited,
> > The Mansion,
> > Bletchley Park,
> > MK3 6ZP,
> > UK.
> > ----- Original Message -----
> > From: "Allan McInnes" <amcinnes@xxxxxxxxxx>
> > To: <occam-com@xxxxxxxxxx>
> > Cc: <java-threads@xxxxxxxxxx>
> > Sent: Thursday, February 22, 2007 3:09 AM
> > Subject: Re: Concurrent programming coming to JavaScript
> >
> >
> > > It's probably worth noting that Will Clinger (mentioned in the extract of
> > > Brendan's blog) did a bunch of work on the Actor model of concurrency. So
> > > it's
> > > possible that's the direction that Javascript will end up going for
> > > concurrency. The Actor model shares a lot of ideas with CSP, but also has
> > > a few
> > > key differences, e.g. asynchronous rather than rendezvous communications,
> > > and
> > > message delivery based on the identity of the receiver rather than via
> > > channels
> > > (Erlang, for those familiar with it, uses a message-passing approach along
> > > the
> > > lines of the Actor model).
> > >
> > > Of course, it's pretty straightforward to build a CSP-like channel-based
> > > rendezvous messaging system on top of an Actor-style system, so Tom's idea
> > > of a
> > > CSP library should be feasible even if Javascript does take the Actor
> > > route
> > > instead of the CSP one. Either approach would be a vast improvement over
> > > threads with shared state.
> > >
> > > Allan
> > >
> > >
> > >
> > > Quoting Tom Locke <tom@xxxxxxxxxxxxx>:
> > >
> > >> Hi All,
> > >>
> > >> I find the following to be of extreme importance to us CSP lovers:
> > >>
> > >> Brendan "JavaScript" Eich wants to include *useable* language-level
> > >> support for concurrency into JavaScript 3
> > >>
> > >> Key quotes:
> > >>
> > >> A requirement for JS3 (along with hygienic macros) is to do
> > >> something along these more implicit lines of concurrency support. In
> > >> all the fast yet maintainable MT systems I've built or worked on, the
> > >> key idea (which Will Clinger stated clearly to me over lunch last
> > >> fall) is to separate the mutable unshared data from the immutable
> > >> shared data. Do that well, with language and VM support, and threads
> > >> become what they should be: not an abstraction violator from hell,
> > >> but a scaling device that can be composed with existing abstractions.
> > >>
> > >> So here's a promise about threads ... JS3 will be ready for the
> > >> multicore desktop workload.
> > >>
> > >> Link: http://weblogs.mozillazine.org/roadmap/archives/2007/02/
> > >> threads_suck.html
> > >>
> > >> There is a growing belief that Ecmascript / JavaScript is about to
> > >> become The Next Big Language. Static typing is being added, as well
> > >> as other "in the large" features. Performance is becoming competitive
> > >> with Java. I think it's already the most widely known language...
> > >>
> > >> Some of you heavy-hitters really need to start up a dialogue with Eich.
> > >>
> > >> Of course the future is always murky, but there's a pretty real
> > >> possibility that this is *the* opportunity to take the CSP ideas we
> > >> love mainstream. An opportunity such that has never existed and may
> > >> never again.
> > >>
> > >> At *least* it might be possible to steer things such that the
> > >> primitives can support fine-grained, high performance CSP via a library.
> > >>
> > >> Peter - remember your CSP workshops at Sun where you convinced (IIRC)
> > >> everyone except Gosling? Time for a re-run at the Mozilla foundation!
> > >> These open-source types are much cuddlier than corporate lackeys
> > >> y'know :-)
> > >>
> > >> Time to act!
> > >>
> > >> Tom
> > >>
> > >>
> > >
> > >
> > > --
> > > Allan McInnes <amcinnes@xxxxxxxxxx>
> > > PhD Candidate
> > > Dept. of Electrical and Computer Engineering
> > > Utah State University
> > >
> > >
> >
>
>
> --
> Allan McInnes <amcinnes@xxxxxxxxxx>
> PhD Candidate
> Dept. of Electrical and Computer Engineering
> Utah State University
>
> ----- End forwarded message -----
>
>