[MLton] MLton import headers

[Matthew Fluet]

On Thu, 2 Oct 2008, Wesley W. Terpstra wrote:
> Thoughts?

The whole set of shared-library/visibility issues seems fairly opaque (a 
reflection on the ABI itself, not its realization in MLton).  From some 
of the scenarios that Wesley has described, it often seems to be the 
case that one has to be very clear on how a program/library links to other 
libraries, how a library is generated depending on its future use, etc. 
Things seem sufficiently complex that it is unclear whether a complicated 
set of implicit defaults is enough to shield a programmer completely (or 
even mostly) from the details of which they need to be aware.  If that is 
the case, then it is often simpler to allow/force someone to be explicit 
up front, since that may be easier than trying to back out of the implicit 
defaults when the need arises.

Also, picking up a theme similar to one that Vesa raised, is it so 
difficult to set the visibility of an imported library at configure/build 
time of a target.  For example, something like:

---foo_import.src---
structure Foo = struct
   val libopen = _import "foo_open" FOO_SCOPE: int * string vector -> unit;
   val libclose = _import "foo_close" FOO_SCOPE: unit -> unit;
end
------
---Makefile---
FOO_SCOPE=public

foo_import.sml: foo_import_src
 	sed 's|FOO_SCOPE|$(FOO_SCOPE)|' < foo_import.scc > foo_import.sml
------

where the 'FOO_SCOPE=public' in the Makefile could either have been 
determined at configure time (depending on the availability of libfoo.a or 
libfoo.so) or left blank to be set at the 'make' invocation.

Finally, importing a MLton library (either static or dynamic) into another 
MLton library or executable seems to be a fairly obscure usage. 
Independent of the fact that MLton is a whole-program compiler (which 
benefits from exposing all of the SML code code the compiler at once), I 
don't know of any high-level language implementation (e.g., OCaml, GHC) 
that prefers to import language-native libraries as though they were 
language-independent system libraries.  [One might argue that CLR/.NET is 
an exception, but, really, the 'language-native library' in that instance 
happens to be .NET assemblies.] It is almost certainly a win to have all 
high-level language code sharing the same instance of the runtime/GC/etc.