Re: code mobility for lua: an (old) lexical approach

[Stefan Reich <stefan.reich.maker.of.eye@...>]

Funny how code mobility turns up in an unrelated post just now - after it was declared "totally unimportant" by the Know-It-Alls of lua-l... :-) Oh boy - when will you people learn? When will you get back to the edge of innovation? It's interesting there, come join the front troops! No danger over there: just fun.

So... yes, code mobility IS important these days - and just these questions are what we want to tackle with new approaches:

"The usage problems are the security nightmare of making sure stray 
references to sensitive objects do not escape, and that RPC does not 
really scale beyond a LAN--especially when you can accidentally be 
ping-ponging calls because you forgot to pick up the compute server's 
version of ipairs().[1]"

I think my stance here is that crossing computer boundaries in a computation should usually be explicit. Not complicated, of course - but explicit. Just as concurrency should usually be explicit, to make clear where non-deterministic behavior lurks.

Transparent network calls are nice, but tend to screw up determinism :-)

In Mobile Lua, the fundamental distributed execution concept is the "jump" -  a Lua agent travelling to another machine. Well, and we'll of course have inter-agent communication too.

Stefan

On Sat, Sep 22, 2012 at 12:28 AM, Jay Carlson <nop@nop.com> wrote:

I think I mentioned this once before but Lua 5.2 may be a decent basis to implement the Obliq distributed object model. See http://lucacardelli.name/Obliq.html for papers; here's the Lua-flavored summary:

The cute trick is that during an RPC call, code and values move over the network but references (such as upvals and tables) are replaced with network references pointing back to their defining scope. You are welcome to call

  compute_server(function() os.exit() end)

as "os“ remains lexically bound to the os on the *calling* machine. Which means you just took the long way to call your local os.exit().

But what if you want to use functionality on the compute-server end? Real compute servers will pass in the services they are willing to provide in a sanitized version of their local environment:

    c_s(function(services) services.os.exit() end)

The implementation problems are a robust RPC which marshals network references, and then of course distributed GC. The usage problems are the security nightmare of making sure stray references to sensitive objects do not escape, and that RPC does not really scale beyond a LAN--especially when you can accidentally be ping-ponging calls because you forgot to pick up the compute server's version of ipairs().[1]

Still, within certain problem domains it might be useful, and a fun student project. The real art would be figuring out how to restrict the environment such that the above problems never bite you.

One obvious thing is to make it easy to deep-copy tables as part of function call itself. An optimizer for

  remote_f(deepcopy(t))

could notice there cannot be any stray references to the table deepcopy(t) lying around and is therefore safe to send as a value rather than a reference--no need to actually do the deepcopy in fact. Any mutations to deepcopy(t) can't be noticed either.

Jay