[MLton] MinGW port

[Brent Fulgham]

> By leaving the code alone, you kept the rename from
> happening.  I'm wondering what the right thing to do
> is, though.

For MinGW I think the right thing is to *not* rename
the file, since all the executables are expected to
have *.exe extensions.  Remember, MinGW is trying to
produce real native Win32 executable, not UNIX-y stuff
like Cygwin, so it *wants* to look like a windows app.
 
> > >    A. Remove them from the signature
> > >    B. Raise SysErr in SML
> > >    C. Treat as noop in SML
> > >    D. Return -1 from C, hence causing SysErr to
> be
> > > raised
> > >    E. Treat as a noop in C
> ...
> > I agree that (B) would be a better option.  I
> think it
> > is appropriate to raise an error on an
> unimplemented
> > function.
> ...
> > I vote for option (C), which would be to document
> > that the functions are not available, then provide
> > the working implementations we have to that the
> > Intelligenci can secretly use them for nefarious
> > ends!
> 
> I'm confused.  I guess you're agreeing that (B) is
> better than (D),
> but saying that (C) is best of all?

No!  I was trying to make a joke (poorly).

I should have said option (X) -- I just mean that
instead of removing the functionality, we should have
any unimplemented code raise the error but keep what
we have implemented.  Then indicate that the
functionality for POSIX is not present for Win32
builds (even though there is *some* functionality). 
If/when the rest of the POSIX layer is supplied, it
can then be documented as such.
 
> > If we just don't document the versions that exist,
> > we can slowly include more functionality until the
> > POSIX layer works.
> 
> I am happy to continue to improve our Posix
> emulation, but I still
> think it's best in the meantime for functions that
> are not emulated to
> raise SysErr.  A noop will cause too many hard to
> debug errors.

I agree.  I just expressed the idea badly!

Summary:

1.  Raise SysErr for any unimplemented code (in the
MLton library).
2.  Leave any working POSIX stuff in place.
3.  Don't document that any POSIX layer exists for
Win32 until it all works (or at least until a
significant subset works).
 
-Brent