new syntax - a provocation

[Richard A. O'Keefe]

I 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.

I should also have mentioned the University of Washington "Emerald"
system/language.

Luke Gorrie <luke@REDACTED> asked:

	And also the question: why would you want to? Seriously.
	
Surely the answer is obvious?  To reduce *total* communication costs.
Suppose you have two processes X and Y, and two machines A and B.
Process X is running on A and Y is running on B.

Now process X discovers that it is going to communicate *lots* with
Y for a while.  So X moves over the machine B, has a nice long chat with
Y, and then moves back to A.

Depending on exactly what the situation is, it may be possible for
X to spawn a process Z on B, send it some background information,
wait for Z to chat with Y, and then read Z's suicide note.

It's nice to have a single language mechanism (move process to node)
instead of relying on a different ad hoc solution for each of many
programs.  Erlang shouldn't have any extra problem with moving code
over; if you are going to do spawn(M, F, [E1,...,En], Node) then you
had _better_ be perfectly sure what Node thinks M means anyway.

However, I wasn't suggesting that Erlang *SHOULD* be made to suppose
between-node process migration, only that it's worth *thinking* about
what it would take to do that.