new syntax - a provocation

[Joachim Durchholz]

Luke Gorrie wrote:

>>It's interesting to consider the question:  "what would an Erlang
>>implementation have to be like for us to be able to take a running
>>process and move it to another processor?"  (IBM's AIX was able to
>>do this on their mainframes, I believe.  I think Kali Scheme can do it.
> 
> And also the question: why would you want to? Seriously.

Code upgrading for a set of communicating nodes, for example.
(I haven't done this yet in Erlang, so the current methods may be 
enough. OTOH I suspect that such an upgrade could make good use of some 
automation, and that the Kali ideas are a step in the right direction.)

> Kali Scheme looks extremely complex and subtle to me. In Kali you can
> capture a process and send it to another machine, and it will
> magically transport the related code on-demand, do distributed garbage
> collection, and so on.

Transporting the related code is trivial (in the sense that you need no 
rocket science to do that). Just patch up all calls to 
not-yet-transported functions with a stub that loads the code from the 
original location, for example - that's the lazy variant. Eagerly 
transporting the code is even simpler.

 > It even lazily copies the processes, sending
> just a few stack frames and copying the rest on-demand. This all
> strikes me as terrifying - what happens if something fails, when
> everything is so interconnected? I believe they assume that nothing
> will fail, which makes it a completely beast than Erlang.

You can do this all both lazily or eagerly. Both would have their place 
even in Erlang - as a very fast-and-loose application, I'd copy 
everything within an application eagerly and the connections between 
applications lazily (because failure is an option there).

Anyway, I think Richard was more interested in code migration than in 
lazy copying :-)

Regards,
Jo