Re: [fonc] An actor-based environment for prototyping
Paul, In my humble opinion, Google Android Intents is just a demonstration of a complete non-understanding of how to implement discoverability in a dynamically distributed, dynamically federated system. The gist of the problem is that developers don't realize the right way to frame the problem, so when they reason about trade-offs they're thinking with the wrong set of constraints. The documentation for Android pretty much says it all, in how they describe usage patterns for Intents and Intent Filters. -- It should be fundamentally obvious to anyone who reads the Docs on Google's Android site that this is an abomination. Unfortunately, nobody seems to get it. You know, Peter Deutsch wrote the 8 Fallacies of Distributed Computing a long time ago, and no matter how many dollars are lost due to ignorance or ignoring it, people continue to make these fundamental system design mistakes. What should we be doing about it? On Sat, May 15, 2010 at 9:16 AM, Paul D. Fernhout < pdfernh...@kurtz-fernhout.com> wrote: > Alan Kay wrote: > >> 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). >> > > Alan- > > It's not quite as general as what you describe, but (forty years later) the > Google Android platform has an aspect of this (where an "activity" mentioned > below is usually a Java class that implements one small window's worth of > user interaction and then depends on other activities to bring up other > windows, but in a way could be seen as an "actor"). See: > http://developer.android.com/guide/topics/fundamentals.html > """ > Content providers are activated when they're targeted by a request from a > ContentResolver. The other three components — activities, services, and > broadcast receivers — are activated by asynchronous messages called intents. > An intent is an Intent object that holds the content of the message. For > activities and services, it names the action being requested and specifies > the URI of the data to act on, among other things. For example, it might > convey a request for an activity to present an image to the user or let the > user edit some text. For broadcast receivers, the Intent object names the > action being announced. For example, it might announce to interested parties > that the camera button has been pressed. > """ > > So, forty years later... Truly, as you say, the computer revolution has not > happened yet. :-) > > --Paul Fernhout > http://www.pdfernhout.net/ > > The biggest challenge of the 21st century is the irony of technologies of > abundance in the hands of those thinking in terms of scarcity. > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
Alan Kay wrote: 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). Alan- It's not quite as general as what you describe, but (forty years later) the Google Android platform has an aspect of this (where an "activity" mentioned below is usually a Java class that implements one small window's worth of user interaction and then depends on other activities to bring up other windows, but in a way could be seen as an "actor"). See: http://developer.android.com/guide/topics/fundamentals.html """ Content providers are activated when they're targeted by a request from a ContentResolver. The other three components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents. An intent is an Intent object that holds the content of the message. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. For example, it might convey a request for an activity to present an image to the user or let the user edit some text. For broadcast receivers, the Intent object names the action being announced. For example, it might announce to interested parties that the camera button has been pressed. """ So, forty years later... Truly, as you say, the computer revolution has not happened yet. :-) --Paul Fernhout http://www.pdfernhout.net/ The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those thinking in terms of scarcity. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
On Tue, May 11, 2010 at 3:16 AM, Michael FIG wrote: > Hi, > > Dale Schumacher writes: > >> 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. > > I have a relatively simple model in mind that's probably a cheap > ripoff of Prolog, LINDA, and term-rewriting systems. > > Let me know if you see merit in it: > > http://michael.fig.org/first.html It looks very interesting, especially the example of locating "sine". I'd like to learn more about this. Do you have more information online somewhere? I've just launched a new blog to start publishing thoughts about the design and implementation of reliable, scalable, massively-concurrent actor-based systems. If you're interested, you can subscribe at http://www.dalnefre.com/ I'm aiming for a bi-weekly publication schedule and have just put up the first post. Comments are always welcome! ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
Sussman's in particular is well worth reading. Cheers, Alan From: John Zabroski To: Fundamentals of New Computing 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 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 > >To: Fundamentals of New Computing >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 >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 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
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 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 > > *To:* Fundamentals of New Computing > *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 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
Re: [fonc] An actor-based environment for prototyping
Yes. I cited the reference with more bibliographic information, but I actually downloaded the paper from the CSAIL link that John quoted. I just wanted to be sure it was the right paper :-) On Tue, May 11, 2010 at 9:20 AM, Alan Kay 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 > To: Fundamentals of New Computing > 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 > 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. ... >> On Mon, May 10, 2010 at 7:28 AM, Alan Kay 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)). ... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
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 To: Fundamentals of New Computing 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 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 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 fro
Re: [fonc] An actor-based environment for prototyping
rol 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 > > To: Fundamentals of New Computing > > Cc: Tristan Slominski ; Steven Teleki > > ; Dion Stewart ; John Heintz > > ; Ian Buchanan ; David West > > > > 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 > >
Re: [fonc] An actor-based environment for prototyping
Hi, Dale Schumacher writes: > 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. I have a relatively simple model in mind that's probably a cheap ripoff of Prolog, LINDA, and term-rewriting systems. Let me know if you see merit in it: http://michael.fig.org/first.html -- Michael FIG //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
d 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 > To: Fundamentals of New Computing > Cc: Tristan Slominski ; Steven Teleki > ; Dion Stewart ; John Heintz > ; Ian Buchanan ; David West > > 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
Re: [fonc] An actor-based environment for prototyping
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 To: Fundamentals of New Computing Cc: Tristan Slominski ; Steven Teleki ; Dion Stewart ; John Heintz ; Ian Buchanan ; David West Sent: Sun, May 9, 2010 4:38:20 PM Subject: [fonc] An actor-based environment for pro
Re: [fonc] An actor-based environment for prototyping
On Sun, May 9, 2010 at 8:39 PM, Steve Dekorte wrote: >> On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher > Are the messages that a Humus actor sends internally (calling methods on > itself, etc) also asynchronous? And if so, does this mean that a given > instance will never need more than one (potentially recyclable) locals > context per method? All actor messages are sent asynchronously. Actors don't "call" methods, as that implies a "return" value. They only send immutable values as messages. When a message is received, the actor's behavior is invoked in a context including the message value and the actor's state. Messages are processed atomically, but this can't lead to dead-lock since an actor's behavior never blocks. In terms of resource usage, it would be more accurate to think of needing one (recyclable) context per concurrent message delivery. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
> On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher > wrote: >> >> Humus is a pure actor-based programming language Hi Dale, Are the messages that a Humus actor sends internally (calling methods on itself, etc) also asynchronous? And if so, does this mean that a given instance will never need more than one (potentially recyclable) locals context per method? Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
Congrats on sticking with your work Dale. I'm impressed. On Sun, May 9, 2010 at 6:38 PM, Dale Schumacher wrote: > 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] 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
