[MLton] Re: [MLton-user] SVN r6941 MLton/MinGW32 and FFI

[Matthew Fluet]

On Tue, 11 Nov 2008, Wesley W. Terpstra wrote:
> On Tue, Nov 11, 2008 at 7:04 PM, Matthew Fluet <fluet at tti-c.org> wrote:
>
> It sounds from your
> later comments that you agree with me, so let's just phase
> GC_arrayLength out of the examples and FFI documentation.

Agreed.  I think most of the documentation on the wiki is pulled directly 
from the SVN repository, so that will be updated when the examples are

>> Personally, I think that MLton should not be attempting to provide
>> non-essential functionality that is missing on a platform.
>
> I agree, with the added provision that if MLton needs these functions
> itself it implement them, but not export them.

I can't forsee a reason why, but, in principle, I agree that the MLton 
runtime shouldn't export more than necessary.

>> MLton doesn't
>> default to including those link options, because they are not essential
>> functionality (e.g., required by some of the Basis Library implementation).)
>
> So why were the dl* functions added to mingw.c in the first place? The
> only reason I suggested keeping them (and the GC_arrayLength stuff)
> around was because I thought there was a reason for them that I didn't
> know.

Looks like the origin was to get mlnlffi working on MinGW:
   http://mlton.org/pipermail/mlton/2006-November/029349.html

The original issue there (using dlopen(NULL,...) to get a handle on the 
process local instance of 'malloc' and 'free') is no longer an issue, as 
'malloc' and 'free' are _import-ed.

There remains an issue that the DynLinkage module as exported by the 
mlnlffi library expects to find dl{open,close,sym,err,...}.  [One needs to 
use DynLinkage to implement the library handle expected by mlnlffigen 
-dynamic generated code.] As noted elsewhere in this thread, there are 
multiple ways to get around this issue:
  - Use the dlfcn-win32 library when using the mlnlffigen generated code.
  - Implement a Win32 version of DynLinkage, use MLB path-variables so that
    the mlnlffi library uses the correct version of DynLinkage.
    (Effectively, implement dlfcn-win32 in SML.)

>> - MLton shouldn't be providing dl{open,close,...} in any form.
>
> If the basis doesn't use them, then I agree and further suggest they
> be removed from mingw.c.

Agreed.

>> - GC_getArrayLength isn't advertised, so there is no need to 'bless' it
>>  with a MLton_getArrayLength name.  (We should eliminate its use from the
>>  <src>/doc/examples/ffi examples.)
>
> Be aware that even the wiki advertises this function at the moment.

I think these uses are all pulled directly from the SVN repository 
examples.