[MLton] Serialization?

Matthew Fluet fluet@cs.cornell.edu
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?

See above.

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