Dynamic library issues...

[Stephen Weeks]

I would like to prefix this mail by saying that I am very inexperienced with
dynamic libraries, so everything I say should be taken with a grain of salt.

> I guess the main problems to be solved are:
> 1) Generate the library with MLton
> 2) Load and use libraries with MLton
> 3) Getting garbage-collection to work
>    across the library boundaries.
...
> ...Hey! I just got an idea! :)
> Problem 3) Could be solved by putting the
> GC in a library! Then all libraries as well
> as the main program could just load
> that - then users could even choose
> their own GC, if several existed! ;)
> I'm sure that would be do-able :)

I think there's a fair amount of work in getting (1) to work in MLton.  One
problem is the whole program assumption.  You would need some way of indicating
to MLton which functions should be entry points in the library.  Propagating and
using this information in the compiler might require substantial modifications.
If it is possible to view every invocation of the library as a complete run of
the whole program, and the heap is not shared across applications, it doesn't
seem insurmountable though.

As a really gross hack using the current compiler, you could write your own
wrapper and Main macro in C to make the library.  You could store the parameters 
to each routine in globals and set a flag indicating which routine should be
called.  You could then call the MLton main procedure, which would dispatch on
the flag and access the parameters stored in globals via the FFI mechanism.

> Just come to think of it - there are 2
> more potential problem in creating dynamic
> libraries:
> 
> 1) Linking the implementation of a
>    function with a known signature to
>    an ML function at runtime.
> 2) Passing arbitrary data-structures as
>    function arguments.

Problem (2) is already present in MLton's FFI interface.  My feeling is that it
shouldn't be too hard to load dynamic libraries within MLton, provided that the
routines being called have types that MLton's FFI can handle.  Accessing or
creating ML data structures from C code is not easy, and will not happen in the
forseeable future.

> I have attached the Dynlib.sig from
> MoscowML - so that you don't have to
> search for it if you want to see it :)

Something like this should be doable.  In fact, if you have a particular case
where you need just a few functions, you might be able to build it yourself
using MLton's FFI mechanism.