[MLton] Support for link options in ML Basis files

Stephen Weeks MLton@mlton.org
Mon, 17 Jan 2005 19:07:20 -0800


>  * MLton's FFI isn't expressive enough to pass a struct/union from ML to
>    C.  I can fake it on the x86 because the calling convention is to pass
>    the struct "in pieces", so one can simulate the call by extracting the
>    struct fields and passing them in order.  Unfortunately, this doesn't
>    work on all architectures.

Can we avoid portability problems by automatically generating a
wrapper to translate between the calling convention we understand
(n-ary C functions with basic types) and the calling convention we
don't (passing C structs)?

For example, if someone does

   _import "f": char * {x: int, y: double} -> unit;

then on the SML side we turn this into

  fn (c, {x, y}) => _import "f_wrapper": char * int * double -> unit; (c, x, y)

and on the C side we produce the following:

----------------------------------------
struct zzz {
	int i;
	double d;
};

void f (char c, struct zzz z);

void f_wrapper (char c, int i, double d) {
	struct zzz s;
	s.i = i;
	s.d = d;
	f (c, s);
}
----------------------------------------

>  * mlnlffigen also has it's shortcomings, independent of MLton.  The most
>    glaring of which is that it doesn't export #define constants.  It is a
>    recognized problem, but as of right now there doesn't appear to be a
>    solution out there.  I suspect it requires modifying the ckit Library.

Might it work to use the same approach that we use for
build/lib/<target>/constants?