[MLton] NLFFI

[Matthew Fluet]

> Regarding _dimport, would it be possible to think of _dimport as the
> primitive and implement _import in terms of _dimport by adding another
> primitive like _symbol?  So,

I don't necessarily think it is a good idea.  If

   _symbol "f" : Word32.word (* MLton.Pointer.t *)

and

     e : Word32.word
   -------------------
   (_import e : t) : t

Then it seems to me that the codegen will end up doing:

   (_dimport (_symbol "f"): int -> unit;) 1

as

   movl f,%eax
   pushl 1
   call (%eax)

And, I think that is bad for the processor, because calls are nicer when
they are PC relative addresses.

Arguably, it's just something for the processor to clean up after.  But, I
think that calling a static name and calling a dynamic value are fairly
different.

> For now, I'd like to keep the mlb files more focused on being in the
> clean SML world and having a clean semantics.  To solve the above
> problem, it seems better to me to adopt some convention or let our
> users figure one out, like including a top-level Makefile in each
> distributed library that has a phony "mlton-compile-options" target
> that prints out the needed options.  Yeah, it's not so composable or
> clean, but that may be a more accurate reflection of the real world
> than putting annotations in mlbs.

O.k.  I wasn't overly excited about it.