Hey,
How you'd go about it would depend on how seamless you want it to
be. If you don't mind losing the concurrent processing of futures,
future's could easily be added via tables, userdata or a custom
type, with minimal changes to the lua c code. (Would have to change
the comparison code, arithmetic handling could easily be implemented
via metamethods). Wouldn't be hard at all to do, and who knows
might save the odd clock cycle when a value is computed but never
required, along with making good proof of concept. (Of course on
the stack the value would stay as a table, but you'd make it so the
value is stored away once the function has completed, making its
access quick).
To allow concurrency would be hard work. You could simulate it a
bit by representing futures with coroutines, with a coroutine
dispatcher thread, and each future/main thread yielding at key
points - but it's a bit unwieldy for this purpose. Would appear
completely multithreaded though, with expensive functions not
blocking the code. And has the advantage that when a good make-
coroutines-concurrent patch comes along, it'd all work beautifully.
Or if hung up on true concurrency now, could try representing
futures as userdata, with each userdata spawning a whole new lua
state. You'd have no access to globals, etc (but then how do these
work in "futures"?), but there'd be no inherent problems in running
each state in its own thread. Very expensive though.
To improve on that (concurrency within a lua state) would require
everything that simultaneous coroutines requires, so there isn't
much point. Perhaps look to lua lanes (which I believe defines
global locks around pretty much every lua function).
I'll be interested to see what you come up with though :).
- Alex
