One big issue to note is that, because of Refs, Clojure agent semantics can't simply be remoted the way Erlang processes can be. This is because a message send could include a references to a Ref, thus exposing mutable state remotely. This breaks, well, just about everything.
If you restrict the acceptable arguments to message sends to include only fully functional values (no passing Refs), then your agent-proxy idea could probably be made to work. I'm guessing the tricky code won't be the remote equivalent of "send", but rather the remote equivalent of "wait", as that requires keeping track of where the remote sends come from, in a stable and machine-independent way. The current Clojure implementation seems to do that internally via uuids, but accessing those remotely could be tricky. For extra bonus points, allow for multiple pluggable protocol stacks and automatic protocol negotiation (which Erlang has, IIRC). Unlike some of the other comments in this thread, I'll say I believe that remote agents in Clojure could be a very powerful idea, particularly due to integration with the STM. Orchestrating in- memory and eternal communications takes an enormous amount of effort in many systems. Having a software transaction which automatically queues up remote agent sends so that they only occur once the transaction completes sucessfully would be a very powerful language- level primitive. Code it up and give it a try! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
