http://publications.csail.mit.edu/lcs/specpub.php?id=773
MIT has catalogued for free basically all their CS papers ever. -- Most Ph.D.'s require going through a clearinghouse to acquire and will set you back a chunk of monies. On Mon, May 10, 2010 at 11:37 PM, Dale Schumacher <dale.schumac...@gmail.com > wrote: > Hi Alan, > > Thanks for the encouragement. After a little searching I found > "Naming and Synchronization in a Decentralized Computer System", D. P. > Reed, 1978 [1]. Is that the paper you had in mind? It looks > interesting, but I haven't had a chance to absorb it yet. > > I'm glad to hear we're on the right track regarding Actors. At this > stage, I'm working at the small end of the continuum, focusing on a > small number of powerful and composable mechanisms. I'm about to > launch a new blog to discuss some of our findings. I'll post > something here when it's available. > > I'll have to give some thought to the larger-scale blackboard > mechanism. It seems like it will take a few combined abstractions to > get there. Some kind of "unification" or "matching" along with > perhaps an "auction" or "marketplace". Maybe the work of the > complexity folks, using Agent-Based Modeling, could inform this > effort. I think there's more foundational work to do before I'll be > ready to tackle these issues, but it is good to let it percolate. > > I'm convinced that there is important progress to be made using > actors, and I plan to continue in that vein. > > Thanks again, > Dale > > [1] http://portal.acm.org/citation.cfm?id=889815 > > On Mon, May 10, 2010 at 7:28 AM, Alan Kay <alan.n...@yahoo.com> wrote: > > Hi Dale et al. > > > > This sounds like a great project, and I'd like to find out more. (Have > you > > looked at David Reed's 1978 MIT thesis on "distributed transactional > object > > operating systems". In my opinion this was one of the very best next > steps > > wrt objects (and it was influenced by Actors)). > > > > And you are right that Actors were closer to my original concept of > objects. > > Actors came out of the first implemented Smalltalk (72) (which was very > > "Actor-like") -- my notion of objects was heavily influenced by the > ARPAnet > > and the soon to be Internet -- and Actors stayed with something more like > > this and were both a great next step from what we were doing at PARC, and > > also got to some of the theoretical issues better than we did. The drive > at > > PARC was to invent and build personal computing, and to try to do it in a > > language that children could program in. (The former succeeded better > than > > the latter.) > > > > After the first round of hardware and software design and implementation, > > Xerox was unwilling to fund the next logical machine after the Alto > > (eventually they did but too late), and this forced the fringe people > (us) > > to have to optimize software for the first time (we had been making > things > > run fast enough via HW). And this brought forth rather different versions > of > > Smalltalk which were less adventurous than the original but much more > > practical (Smalltalk-76 was about 180 times as fast as Smalltalk-72). > > > > Carl Hewitt's research was not primarily aimed at building whole > real-time > > systems, so Actors and Smalltalk diverged quite a bit. > > > > However, I still think the most interesting version of Smalltalk was "71" > > which was never implemented [1]. It was an attempt to combine my earliest > > notion of objects, LOGO, Carl Hewitt's most interesting work (PLANNER, > which > > was the strongest influence on the later Prolog), and some of David > Fisher's > > control definition ideas. This was what we called "pattern directed > > invocation" or "call by desire". Smalltalk-72 was a weaker version of > this, > > and it's hard to see at all in Smalltalk-80 (a programmer really has to > want > > to program this way to do it). > > > > Also in [1] towards the end, is a discussion of how many improvements in > > software came from improvements in late binding, and that some of these > > eventually got put into HW to remove most of the inefficiencies that > usually > > come with late binding something. When LINDA came along in the 80s, this > got > > me thinking harder about the step to "call by need". This was already in > > PLANNER as "antecedent theorems" (Prolog only tried to do the "consequent > > theorems" which have a control structure that allows "backwards > reasoning", > > and is rather similar to procedure calls). CMU had been doing > considerable > > explorations into "forward reasoning" (OPS-5) with some terrific > > optimization mechanisms (Forgie et al). LINDA provided a kind of > > metaframework for pretty much building any kind of control structure and > > these could be driven by patterns. These allowed one to think about a > kind > > of goal oriented publish and subscribe coordination mechanism in which no > > messages were sent (but in which messages were only received). > > > > One way to think of this is that each object has two "bulletin boards". > One > > has characterizations of needed resources, and the other has > > characterizations of resources made available by the object. These > bulletin > > boards are now all put into a LINDA-like matching space which does the > > (considerable) work of brokering. If one could come up with a great way > to > > express the characterizations, then one would have removed one of the > > difficulties of scaling a message sending system, by removing the need to > > know the name or IDs of the receivers. In effect, one would not send > > messages, but only receive them. > > > > I think the big power here would be in finally getting more strongly to a > > more independent but highly practical way to provide semantics. (One of > our > > favorite examples over the years is the question "if you don't know the > name > > of the sine function, then how could you still invoke it?" ... APL has a > > very funny completely non-intuitive way of naming sine, etc.) This > question > > is a very good question when you are trying to find powerful and useful > > resources on a large network .... > > > > People who have taken the trouble to really understand and build Actor > > systems (like you!) are well set up to ponder and design and criticize > one > > of the next logical qualitative leaps in object design and communication. > > > > Cheers, > > > > Alan > > > > > > > > > > [1] > > http://www.iam.unibe.ch/~ducasse/FreeBooks/SmalltalkHistoryHOPL.pdf<http://www.iam.unibe.ch/%7Educasse/FreeBooks/SmalltalkHistoryHOPL.pdf> > > > > ________________________________ > > From: Dale Schumacher <dale.schumac...@gmail.com> > > To: Fundamentals of New Computing <fonc@vpri.org> > > Cc: Tristan Slominski <tristan.slomin...@gmail.com>; Steven Teleki > > <st...@teleki.net>; Dion Stewart <dion.stew...@visi.com>; John Heintz > > <j...@gistlabs.com>; Ian Buchanan <ibucha...@squian.com>; David West > > <da...@transcendencecorporation.com> > > Sent: Sun, May 9, 2010 4:38:20 PM > > Subject: [fonc] An actor-based environment for prototyping > > > > I've been following with great interest the FoNC developments at VPRI. > > I too am very interested in compact, simple and expressive > > representations of computer-based solutions. My focus for the last > > three years has been on the Actor model of computation [1][2]. It > > seems to me that actors are closer to Alan Kay's original concept of > > "objects" than the implementation of objects realized in Smalltalk and > > its derivatives. As Alan has said, the emphasis should be on the > > messages. In a concurrent environment, the asynchronous messaging of > > actors is a much better primitive than the synchronous call-return > > messaging typical in today's "object-oriented" languages (including > > those based on COLA). In order to explore these ideas, I've developed > > an actor-based environment for protoyping. Within this environment > > I've implemented; a solution to the same-fringe problem, an > > implementation of Joe Armstrong's "Erlang Challenge", a fault-tree > > simulation, a dialect of FORTH, two dialects of Scheme, and a > > meta-circularly-defined actor language called Humus. > > > > Humus is a pure actor-based programming language that provides a > > foundation for software developers to build reliable concurrent > > computer systems. It features a referentially transparent > > pure-functional core for defining values. These values become the > > messages between (and specify the behavior of) dynamically configured > > actors. Actor behaviors are composed of concurrent, rather than > > sequential, primitive operations. Actor configurations may also be > > composed without affecting their operation. This allows > > implementation of systems with high scalability and low latency in > > both multi-core and distributed execution environments. The > > theoretical foundations of Humus have mathematically rigorous > > semantics [3]. Unlike Erlang or Scala, there are no blocking > > operations and all expressions are completely free of side-effects. > > Mutable state is entirely encapsulated within actors and may be > > affected only be sending asynchronous messages. > > > > Some of the implementation techniques used in both Humus and my > > actor-based environment (ABE) were inspired by COLA. OMeta also > > provided insight into the design of numerous parsers for the various > > languages built in ABE. I haven't implemented OMeta directly, but > > believe an implementation is possible. The biggest hurdle to that > > implementation is the specification of semantic actions. If I use the > > host language (Humus) to specify the semantic actions, then I can't > > take advantage of all the useful OMeta "code" written for COLA. It > > seems that I would have to implement COLA (Coke) as well. I would > > love to find a way to connect my work with that of VPRI, to the extent > > that we have shared goals. > > > > [1] G. Agha. Actors: A Model of Concurrent Computation in Distributed > > Systems. MIT Press, Cambridge, Mass., 1986. > > [2] C. Hewitt. Viewing Control Structures as Patterns of Passing > > Messages. Journal of Artificial Intelligence, 8(3):323-364, 1977. > > [3] G. Agha, I. Mason, S. Smith, and C. Talcott. A Foundation for > > Actor Computation. Journal of Functional Programming, Vol. 7, No. 1, > > January 1997. > > > > _______________________________________________ > > fonc mailing list > > fonc@vpri.org > > http://vpri.org/mailman/listinfo/fonc > > > > > > _______________________________________________ > > fonc mailing list > > fonc@vpri.org > > http://vpri.org/mailman/listinfo/fonc > > > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
