On 8/16/2012 4:13, Invisible wrote:
> Similar remarks go for most of your points. There are languages like Erlang
> where support for distributed processing is built-in. Haskell is not such a
> language. On the other hand, we already have a library for shared-memory
> synchronisation and communication between threads; it's not inconceivable
> that some day somebody will extend it to work across node boundaries.

But that's not all it takes to make it do what Erlang does. Erlang isn't 
just "distributed processing." It's "reliable processing." Which means you 
need to be able to (for example) start a new version of the code running 
while not actually throwing away the stack of call frames that got you 
there. You have to be able to have A call B call C call D, and have D say 
"Oh, by the way, next time C returns, B should be calling the new version of 
C, but only in those threads where C has actually returned. Oh, and don't 
screw up B's local variables."  That's the sort of thing that's really, 
really hard to do in a library, unless you're running something like FORTH 
that actually has access to the executing code.

How would you write a Haskell library that says "once each call to X 
returns, replace that thread's version of X with new executable code, 
without otherwise disturbing the thread that's running there"?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message