[MLton] MinGW port

[Stephen Weeks]

> > * In main/main.fun, you added a comment about the
> > renaming of exe files that we do on Cygwin, but 
> > didn't add any code.  Is something missing? 
> 
> I'll review it.  I believe I was trying to stop the
> files from being renamed from "test.exe" to "test",
> but probably did not get that completed.

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

> I used __MSVCRT__ any place a change was not MinGW
> specific, with the idea (since MinGW uses the
> Microsoft
> C runtime libraries) that these changes would be
> proper for a straight Visual C++ build of MinGW.  I
> followed this approach based on how windows ports of
> other software were done.
> 
> The __MINGW32__ #ifdefs are there for things that do
> not apply to a native Visual Studio build of MLton.

Sounds good.  I will keep the distinction as you have it.

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

Even if the documentation says the functions are not available, making
them noops means that people could accidentally use them, which is
bad.

> 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 think some of the critical MLton tools make use of
> the POSIX layer, don't they?  How can these tools
> work in a native Win32 environment (unless they
> all use the OS layer?)

They might.  I would have to investigate if we wanted to kill the
Posix layer on MinGW.  But it sounds like we're all in agreement that
some form of unsupported function is best.  So, I'm not gonna worry
about this.