Re: [fonc] Re: [PiLuD] Actors in Clojure — Why Not ?
I've been using the word 'composition' in the mathematical sense. Relational composition involves taking relations as input and producing a relation as output. Functional composition involves taking functions as input and producing a function as output. Actors composition involves taking actors as input and producing an actor as output. Note the singular on the output. To achieve composition in actors model requires introducing a non-trivial extra element: a serializer. Properly, it really should also involve some extra analysis to ensure that processing is complete prior to any final reply. That is, when one virtual actor is composed of multiple actors, there is risk of producing long-lived 'message loops' within the actor's definition that continue concurrently with processing future replies. Whether you see this issue as a 'problem' is really up to you. When I pursued actors model, I considered actor composition pretty much irrelevant, and instead focused on abstraction and composition of 'actor configurations' to the point of dropping the message-serialization in favor of transactions. But there are plenty more issues to be found once you start dealing with (a) interactions that take multiple messages to complete (e.g. queries followed by updates), (b) multiple client actors sharing a service actor, aka shared resources, (c) a single client actor attempting to coordinate independent service actors, and (d) various combinations of (a,b,c). Concurrency being mediated by message delivery doesn't help much when interesting interactions require multiple messages to complete. Further, some state is often involved in any such interaction - i.e. to allow behavior to depend upon prior messages. Coordination of multiple service actors will always involve multiple messages, multiple responses, and challenges from partial-failure: a rejection from one service half way through coordinating with another. And consider the general case of this: composable coordination, where the actors in the coordination might themselves be performing coordination of multiple service actors. The notion that there is no 'shared mutable state' isn't true in any relevant sense. If ever two actors share a reference to a third, and the latter's behavior is a function of messages received, and they might interleave communications, then you effectively have shared mutable state. All the normal issues of race-conditions and interference will apply. This becomes problematic when interactions require dependence on a message history. I suspect you'll find these scenarios more common once you start considering all the ramifications of concurrent, rather than sequential, composition. You might not see the issues, however, if you focus on 'actors in-the-very-small' - i.e. down at the level of single client to single service interactions rather than at the many-to-many level. On Tue, Jun 22, 2010 at 8:28 PM, Dale Schumacher dale.schumac...@gmail.com wrote: The example of implementing a queue (using a serializer) is definitely part of a meta-circular definition of actor behavior. Serializers are one of the critical mechanisms identified by Hewitt, et. al. long ago. I believe that maintaining multiple virtual configurations of actors provides another important way to partition actor systems. In either case, I don't see the problem in composing actors, especially if they have limited interactions. Since concurrency is mediated by message delivery, and message handling generally represents small finite amounts of computation, independent actor behaviors are interleaved at a very fine granularity. And they can't interfere with each other because they don't have shared mutable state. Of course, when working with traditional threaded systems, the cost of context switching encourages us to do a lot more work between context switches. I think the key to effective actor implementations is a dramatically lower context switching cost, which I have achieved in my prototype. The big mental shift in working with actors is to think in terms of concurrent, rather than sequential, composition. When I start describing the meta-circular definition of Humus, in terms of actors, the inherent pervasive fine-grained concurrency will be more clearly exposed. -- send mail : pi...@googlegroups.com subscribe : pilud+subscr...@googlegroups.com unsubscribe : pilud+unsubscr...@googlegroups.com home page : http://groups.google.com/group/pilud Note: reply address is set to the list -- no need to reply all ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Ancient rumblings about objects, actors, and agents
For the amusement of the list. .Actually only semi-ancient. Here's a Scientific American article I was asked to write about computer software in 1984. http://www.vpri.org/pdf/tr1984001_comp_soft.pdf There are a few hidden jokes along the way. The stuff that is relevant to some of the current discussions is put to the general reader at the end of the page marked 6 (the 4th actual page). I used the just starting to be familiar idea of spreadsheets to explain the idea of zillions of concurrent reactive agents acting like tissues of cells (blood is also a tissue) to make very large systems. (The examples were actually done in the earliest versions of Excel that MS originally prototyped on the Mac with many phone calls up there to try to get them to understand what they should really be doing with spreadsheets. Xerox had already done a secret deep generalization of spreadsheets in Smalltalk for the CIA -- implemented on PARC workstations -- and it was a bit of a challenge to keep straight was was supposed to be kept secret ) Some of these ideas were fueled by previous work at CMU and elsewhere on forward (eager) inferencing systems, by some of Ehud Shapiro's thoughts in 83 about what a Concurrent Prolog might be like (answer: much nicer than Prolog!), by the first few notes about Linda, and by some work I did at the end of the 70s and early 80s about trying to just retrieve rather than sending messages (pulling rather than pushing). Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Reverse OMeta and Emulation
This is not entirely true. Basile Starynkévitch has written GNU MELT [1] as a way to circumvent hard to work with internal representation of GCC by letting you create GCC plug-ins in a Lisp dialect. This basically side-steps the traditional political blockade set-up by RMS. It is very clever, and starting to mature; Basile has fixed a number of issues in how he generates C code. I'm not sure about Gerry Jensen's idea, e.g. how much effort, whether it is worth the effort, etc. Creating a VM for legacy code is also difficult, since it will run rather slow unless you are a really good implementor (for example, the Hercules VM [2] for simulating IBM mainframes is rather slow last I checked due to how it has to intercept and translate instructions into the native architecture). [1] http://gcc.gnu.org/wiki/MiddleEndLispTranslator [2] http://www.hercules-390.org/ On Tue, Jun 22, 2010 at 11:37 AM, Monty Zukowski mo...@codetransform.comwrote: GNU C was explicitly designed to make its intermediate representation hard to work with. LLVM is a more practical choice. Monty On Mon, Jun 21, 2010 at 6:02 PM, Gerry J geral...@tpg.com.au wrote: You may find the concept of semantic slicing relevant: http://www.cse.dmu.ac.uk/~mward/martin/papers/csmr2005-t.pdfhttp://www.cse.dmu.ac.uk/%7Emward/martin/papers/csmr2005-t.pdf There is software at: http://www.cse.dmu.ac.uk/~mward/fermat.htmlhttp://www.cse.dmu.ac.uk/%7Emward/fermat.html One possible path to explore is to take GNU C etc intermediate representation of source as the assembly language of a VM and reverse from that to a more portable VM, as in Squeak or Java. Perhaps Ometa could be combined in some way with FermaT to recognise patterns and port legacy code to a fonc VM ? Regards, Gerry Jensen 02 9713 6004 ___ 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] Ancient rumblings about objects, actors, and agents
You're inspiring, Alan. Words aren't such a good communication means, here, but I'll do my best. Your writing in this article reminds me of how wonderful the world is, and how we're not even just beginning out in terms of possibility (and this brings me so much energy). It reminds me of my habit of loving blank books and blank paper when I was a kid. So much potential! Amazing! Needless to say, I was considered an incredibly strange kid by other kids. An ordinary child would surely only notice a piece of paper - solid form, not pure potentiality - recognised, not seen. The capacity to appreciate the infinite potential, so obvious with children, is often forgotten by adults. I'm always so happy to read your works (and the works of those who surround you), because it's so evident you haven't forgotten it, that you've got a direct link to it, and are reminded by it in every moment. It brings me a huge amount of happiness just to know that there are people like you in the world. Julian. On 24/06/2010, at 5:06 AM, Alan Kay wrote: For the amusement of the list. .Actually only semi-ancient. Here's a Scientific American article I was asked to write about computer software in 1984.http://www.vpri.org/pdf/tr1984001_comp_soft.pdf There are a few hidden jokes along the way. The stuff that is relevant to some of the current discussions is put to the general reader at the end of the page marked 6 (the 4th actual page). I used the just starting to be familiar idea of spreadsheets to explain the idea of zillions of concurrent reactive agents acting like tissues of cells (blood is also a tissue) to make very large systems. (The examples were actually done in the earliest versions of Excel that MS originally prototyped on the Mac with many phone calls up there to try to get them to understand what they should really be doing with spreadsheets. Xerox had already done a secret deep generalization of spreadsheets in Smalltalk for the CIA -- implemented on PARC workstations -- and it was a bit of a challenge to keep straight was was supposed to be kept secret ) Some of these ideas were fueled by previous work at CMU and elsewhere on forward (eager) inferencing systems, by some of Ehud Shapiro's thoughts in 83 about what a Concurrent Prolog might be like (answer: much nicer than Prolog!), by the first few notes about Linda, and by some work I did at the end of the 70s and early 80s about trying to just retrieve rather than sending messages (pulling rather than pushing). Cheers, Alan ___ 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] Ancient rumblings about objects, actors, and agents
Thanks Julian, Here's another oldie about the romance of paper ...http://www.vpri.org/pdf/authoring.pdf I think it was a forword I wrote for a book (one of Mark Guzdial's?) Cheers, Alan From: Julian Leviston jul...@leviston.net To: Fundamentals of New Computing fonc@vpri.org Cc: pi...@googlegroups.com Sent: Wed, June 23, 2010 8:07:54 PM Subject: Re: [fonc] Ancient rumblings about objects, actors, and agents You're inspiring, Alan. Words aren't such a good communication means, here, but I'll do my best. Your writing in this article reminds me of how wonderful the world is, and how we're not even just beginning out in terms of possibility (and this brings me so much energy). It reminds me of my habit of loving blank books and blank paper when I was a kid. So much potential! Amazing! Needless to say, I was considered an incredibly strange kid by other kids. An ordinary child would surely only notice a piece of paper - solid form, not pure potentiality - recognised, not seen. The capacity to appreciate the infinite potential, so obvious with children, is often forgotten by adults. I'm always so happy to read your works (and the works of those who surround you), because it's so evident you haven't forgotten it, that you've got a direct link to it, and are reminded by it in every moment. It brings me a huge amount of happiness just to know that there are people like you in the world. Julian. On 24/06/2010, at 5:06 AM, Alan Kay wrote: For the amusement of the list. .Actually only semi-ancient. Here's a Scientific American article I was asked to write about computer software in 1984.http://www.vpri.org/pdf/tr1984001_comp_soft.pdf There are a few hidden jokes along the way. The stuff that is relevant to some of the current discussions is put to the general reader at the end of the page marked 6 (the 4th actual page). I used the just starting to be familiar idea of spreadsheets to explain the idea of zillions of concurrent reactive agents acting like tissues of cells (blood is also a tissue) to make very large systems. (The examples were actually done in the earliest versions of Excel that MS originally prototyped on the Mac with many phone calls up there to try to get them to understand what they should really be doing with spreadsheets. Xerox had already done a secret deep generalization of spreadsheets in Smalltalk for the CIA -- implemented on PARC workstations -- and it was a bit of a challenge to keep straight was was supposed to be kept secret ) Some of these ideas were fueled by previous work at CMU and elsewhere on forward (eager) inferencing systems, by some of Ehud Shapiro's thoughts in 83 about what a Concurrent Prolog might be like (answer: much nicer than Prolog!), by the first few notes about Linda, and by some work I did at the end of the 70s and early 80s about trying to just retrieve rather than sending messages (pulling rather than pushing). Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Blockade? (Re: [fonc] Reverse OMeta and Emulation)
Whoa, okay. Have to ask. GCC has an intermediate representation that's intentionally hard to work with, and you're saying that Stallman did this as a political blockade? I was under the impression that Clang got started up because some folks found GCC to be too crufty, not too political. This doesn't seem to make sense to me. Maybe I'm missing some context? Can you cite your sources or elaborate on your point? On Jun 23, 2010, at 2:25 PM, John Zabroski johnzabro...@gmail.com wrote: This is not entirely true. Basile Starynkévitch has written GNU MELT [1] as a way to circumvent hard to work with internal representation of GCC by letting you create GCC plug-ins in a Lisp dialect. This basically side-steps the traditional political blockade set-up by RMS. It is very clever, and starting to mature; Basile has fixed a number of issues in how he generates C code. I'm not sure about Gerry Jensen's idea, e.g. how much effort, whether it is worth the effort, etc. Creating a VM for legacy code is also difficult, since it will run rather slow unless you are a really good implementor (for example, the Hercules VM [2] for simulating IBM mainframes is rather slow last I checked due to how it has to intercept and translate instructions into the native architecture). [1] http://gcc.gnu.org/wiki/MiddleEndLispTranslator [2] http://www.hercules-390.org/ On Tue, Jun 22, 2010 at 11:37 AM, Monty Zukowski mo...@codetransform.com wrote: GNU C was explicitly designed to make its intermediate representation hard to work with. LLVM is a more practical choice. Monty On Mon, Jun 21, 2010 at 6:02 PM, Gerry J geral...@tpg.com.au wrote: You may find the concept of semantic slicing relevant: http://www.cse.dmu.ac.uk/~mward/martin/papers/csmr2005-t.pdf There is software at: http://www.cse.dmu.ac.uk/~mward/fermat.html One possible path to explore is to take GNU C etc intermediate representation of source as the assembly language of a VM and reverse from that to a more portable VM, as in Squeak or Java. Perhaps Ometa could be combined in some way with FermaT to recognise patterns and port legacy code to a fonc VM ? Regards, Gerry Jensen 02 9713 6004 ___ 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
