Tue, 5 Jul 2005 09:46:44 -0400 (EDT)
> Assuming Matthew ever makes the bytecode portable ;),
Stephen actually put most of the work into the bytecode codegen. I've
only been fixing things as other changes of mine break it.
> Even if the user is required to serialize things by hand, he would still
> need to be able to ship functions across. Matthew's bytecode seems the best
> way to acheive this, but I don't know how feasible it is to run bytecode
> within an existing MLton application.
There really isn't any support for throwing some bytecodes over the wire
to another MLton application and start executing the bytecode in the
receiver application. As with many things, the whole-program nature of a
MLton application means that almost nothing makes sense out of the context
of its whole-program.
The better way (at least in MLton) of implementing something like the
above is to write the client and server together as one application,
thereby sharing the same code and representation. You would invoke the
server as 'app -server' and the client as 'app -client' (the latter
possibly followed by a MLton.World.save which would potentially throw away
as much of the heap data that won't be accessible by the client).
Unfortunately, you essentially need to write a dispatch loop for the
client, taking requests for functions to call.
> That said, how can I help make the bytecode portable?
Right now, the bytecode isn't at all portable. Like every other codegen,
it compiles a target-dependent program. One way of making it more
portably would be to make "bytecode" a target, rather than just a codegen.
The current difficulty with making the bytecode portable is that we
compile all the C-function calls of the program into a dispatch handled
by the bytecode interpreter. I could imagine a less integrated approach.
Alternatively, one could simply limit the FFI supported by the bytecode to
the FFI needed to implement the Basis Library. We could easily ensure
that each bytecode interpreter on different platforms correctly handled
those C-functions, at the expense of excluding additional C-functions in
the user program.
> Also, what level of interaction is inteded between a MLton-built application
> and bytecode that is run inside it?
> ... for me, I just need to be able to call the 'main' function of the
> bytecode with a parameter and recover the result.
This seems more like remote program execution than mobile code; which
means that OS level solutions might work just as well.