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