calling SML from C

[Stephen Weeks]

> 1) Will this scheme allow the whole program optimizer
>    to potentially inline all basis library funtions used
>    in an ML function called from C? - as I believe it should
>    if things are to be really efficient :)

As long as you mean inlining ML within ML code, yes.  MLton still has the whole
program and will do all its usual stuff.  The dispatcher is the trick that I
didn't think of back in January when you asked a similar question -- it allows
us to export lots of functions via one main function.

> 2) Will this work correctly with garbage collection accross
>    the function call boundaries? (and how?)

GC will only happen during ML code, but if ML function f calls C, which then
calls back into ML function g, a garbage collection can happen during g, and f
must still work when C returns to it.  The idea we have is to run each call to
ML from C in its own thread (not that there will be any sort of pre-emption).
That way there can be lots of calls alive at once.  To get the GC right, we have
to make sure that all of the threads are live somewhere, which shouldn't be too
hard.  Of course, this scheme also also requires that the C side doesn't hold
any pointers to ML data, which should follow from the types of arguments (int,
real, ...) that can be passed back and forth.

> 3) Would it be possible to extend this so that one can put
>    the ML-functions in a separate dynamically loaded library -
>    and even do SML -> SML-dynamic-library calls and
>    C -> SML-dynamic-library calls? :)

I'd like to revisit this question after we get the basic interface working.  Try
us again in a couple of months after we get a release out with the basic 
C -> SML stuff working.