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 > > ________________________________ > 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
