Fri, 2 Jul 2004 09:30:02 -0400 (EDT)
> What is the status and interest in supporting NLFFI?
There is interest and I have started porting/implementing from the sources
in SML/NJ. I decided that to really export CML and NLFFI to users, we
needed some better namespace management, hence the discussion on .mlbs.
> Any timeframes or estimates of doability?
It is certainly doable, and probably wouldn't take much more than a few
days to get up and running. (I'm just not making any promises on
which few days.) Almost certainly by the end of the summer.
The only issue I've come across so far is that MLton's support for calling
foreign functions requires a "string" that corresponds to the symbol that
is called; hence that "string" appears in the final assembly. NLFFI gives
you interfaces to dynamic libraries, so you need to call a function by
it's address. It shouldn't be difficult at all provide a _dimport form
which would take a variable of type Word32.word instead of a string.
> Does NLFFI have any UNIX-side dependencies
> which would prevent it from appearing Windows-side?
NLFFI basically requires dlopen/dlsym/dlclose, with all the Unix
dependencies that may or may not entail.