[MLton] MLton import headers

[Wesley W. Terpstra]

On Fri, Oct 3, 2008 at 10:21 PM, Matthew Fluet <fluet at tti-c.org> wrote:
> 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.

So you would propose that I always require the user to
#define PART_OF_X / STATIC_LINK_X / DYNAMIC_LINK_X before #include'ing
the header?

> ---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

Well, I thought it would be nicer to have
structure FooStatic = struct
 val libopen = _import "foo_open" public: int * string vector -> unit;
 val libclose = _import "foo_close" public: unit -> unit;
end
structure FooDynamic = struct
 val libopen = _import "foo_open" public: int * string vector -> unit;
 val libclose = _import "foo_close" public: unit -> unit;
end
structure Foo = FooStatic (* or whatever a sane default is *)

... my way you can use functors and/or the basis system to do what you
want without having to drop out to make.

> Finally, importing a MLton library (either static or dynamic) into another
> MLton library or executable seems to be a fairly obscure usage.

I was aiming for completeness. Perhaps it's not necessary then to
output an ML import header; if you really need one, you can write it
yourself.

While I agree it's pretty bizarre to have two MLton libraries at once,
I think this could happen if you have pure C programs/libraries that
in turn use ML libraries.