Sussman's in particular is well worth reading. Cheers,
Alan ________________________________ From: John Zabroski <johnzabro...@gmail.com> To: Fundamentals of New Computing <fonc@vpri.org> Sent: Tue, May 11, 2010 8:05:49 AM Subject: Re: [fonc] An actor-based environment for prototyping The link I provided IS to his LCS TR. For OTHER universities, you have to go through a clearinghouse. You can even get Guy Lewis Steele or Gerald Jay Sussman's Ph.D. theses on the same site I linked to, if you want. On Tue, May 11, 2010 at 10:20 AM, Alan Kay <alan.n...@yahoo.com> wrote: But in this case, Dave's thesis would have been an LCS TR, so should be findable (and free) via the CSAIL "historic collections". > >Cheers, > >Alan > > > > ________________________________ From: John Zabroski <johnzabro...@gmail.com> > >To: Fundamentals of New Computing <fonc@vpri.org> >Sent: Tue, May 11, 2010 6:42:50 AM >Subject: Re: [fonc] An actor-based environment for prototyping > > >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/%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 > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
