[MLton] Mzton an MzScheme<->MLton FFI

[Matthew Fluet]

> The work I have done has been on the Scheme side, so I have
> no changes to Fluet's patch from
>
>  <http://mlton.org/pipermail/mlton/2005-July/027603.html>
>
> which has worked fine for me - I hope it will be included
> in svn version?

It wouldn't be hard to push it into the SVN HEAD, but I seem to recall a 
few outstanding issues that need to be tracked down.

Also, you'll need to remind us of the extra flags that need to be passed 
to gcc (when invoked as a linker) to produce a shared library.

> Today I got callbacks working, which were the last major piece missing. 
> To give an impression of what the FFI can, I have attached an example 
> from the documentation.

> The type of this function is int*int -> real array so to export it, one 
> writes
> 
>     val _ = _export "makeUnitVec" : ( int*int -> real array ) -> unit;
>             (RealArrayRoot.return o makeUnitVec);
> 
> The important thing to note here is that we are not exporting 
> makeUnitVec, but (RealArrayRoot.return o makeUnitVec). The function 
> RealArrayRoot.return is nothing but the identity function, but it has 
> the side effect of registering the returned array with the MLton garbage 
> collector. When the Scheme object representing the returned ML array is 
> garbage collected, the Scheme garbage collector will automatically tell 
> the MLton garbage collector that the array has become garbage.

Can you say anything more about this?  How are the two garbage collectors 
communicating information?  Also, there is nothing that ensures that the 
returned ML array isn't moved by a subsequent ML garbage collection, 
which may invalidate Scheme functions that hold onto the array.