[MLton] MLton import headers

[Vesa Karvonen]

On Thu, Oct 2, 2008 at 1:20 PM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
[...]
> One of the problems with using a library is that you need to know how
> you are linking against it. Often programmers can get away without
> knowing, but this breaks down on some combinations of operating
> system, architecture, and definitions.

In C and C++, and particularly on Windows, one often uses macros in
library headers and source files to insert appropriate compiler
specific declarations to mark symbols that are either exported from
the currently compiled DLL or imported from an external DLL. These
macros are often defined in a configuration header of some sort and
one can then easily switch between various linkage options
(static/dynamic library, import/export symbols).

> When using a MLton generated library from another MLton program, there
> is the same problem. _import "foo" public: ...; is appropriate for a
> static link, while _import "foo" external: ...; is appropriate for a
> dynamic link. I was thinking of an output file something like:
>
> signature M1 =
>  sig
>    val m1_open : int * string vector -> unit;
>    val m1_close : unit -> unit;
>  end
>
> structure STATIC_LINK_M1 :> M1 =
>  struct
>    val m1_open = _import "m1_open" public;
>    val m1_close = _import "m1_close" public;
>  end
>
> structure DYNAMIC_LINK_M1 :> M1 =
>  struct
>    val m1_open = _import "m1_open" external;
>    val m1_close = _import "m1_close" external;
>  end
>
> I have intentionally left out PART_OF_M1 because you're better off not
> using the FFI in this case.
>
> Thoughts?

One thing that comes to mind from this is that it would be nice to be
able to switch between static and dynamic linking easily without using
a complicated mechanism at the source level. In fact, I think that
ideally code that uses a library should really be exactly the same
regardless of whether the library is linked statically or
(unoptionally) dynamically. I'm not saying that it isn't possible with
the above format (you need to bind one of the modules, STATIC_LINK_M1
or DYNAMIC_LINK_M1, to a  module that you use in the client code), but
rather that you might want to consider this from that perspective.

One alternative that comes to mind would be to specify as a
command-line option whether one wishes to link statically or
dynamically and MLton would then generate only one set of imports and
the module name would be the same (e.g. just M1) in either case. This
import file generation step could be called as a part of the build
script (for the library) and the resulting module would then be used
to call the library.  Alternatively, the module could be selected in a
MLB file based on a path variable and the library would have
pregenerated import files for both cases (static/dynamic).  In either
case, the SML client code would be exactly the same regardless of
whether the library is linked statically or dynamically.

-Vesa Karvonen