Thanks for the encouragement. I agree that this article skims the surface of a number of deeper issues. That's been part of my challenge in blogging. I want to pack too much into each article. Friends have been advising me to publish shorter pieces more frequently. The result is that I have to explore these off-shoots in subsequent articles, which I definitely plan to do.
Type systems are certainly an area of strong debate. I should point out that some actors will not "reply" _at all_, so the issue of reply type is moot. You could say that a _message_ has a type, but it is not always clear what type(s) an actor will understand. This is especially problematic because an actor can replace its own behavior. The new behavior may understand a very different set of messages, effectively changing the "type" of the interface. I prefer to focus on "protocol" rather than "type". Protocol accounts for changing behaviors over time, based on interactions (messages). For an example of this, take a look at the state-dependent protocol involved in implementing a "queue" (http://www.dalnefre.com/wp/2010/05/composing-actors/#queues). The actors involved in implementing the queue change their protocol to coordinate their updates and thus must be protected by a serializer so they don't receive "outside" requests when they are in the wrong state. On Sat, Jun 19, 2010 at 12:53 AM, John Zabroski <johnzabro...@gmail.com> wrote: > Towards the end, it seems like you also suffer from some hand-waviness. > > Perhaps you could flesh out the hand wavy portions in some future posts. > > In particular, I would focus on how to transitively handle messages. For > example, a common error I see by some academics who are overly zealous about > functional programming and Hindley-Milner type systems is that they believe > if an actor cannot handle a message directly, then we cannot say anything > meaningful about the return type of the reply. This is not true, of course, > it is simply that we need a way to model the union of all reply > possibilities. > > Stuff like partial failure is hard to do elegantly, but does not excuse > hand-wavy explanations. > > Looking forward to your future blogging! > > Cheers, > Z-Bo > > On Fri, Jun 18, 2010 at 10:58 PM, Dale Schumacher > <dale.schumac...@gmail.com> wrote: >> >> Published: >> "Actors in Clojure — Why Not?" (http://bit.ly/9ZUXaQ) >> http://www.dalnefre.com/wp/2010/06/actors-in-clojure-why-not/ >> >> This article provides a counterpoint to Rich Hickey's rationale for >> not including actor-based concurrency in Clojure. >> >> _______________________________________________ >> 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
