[MLton] MinGW port
Mon, 23 Aug 2004 12:16:47 -0700
Brent, I had a chance this morning to read through your patch to port
MLton to MinGW. Thanks again for sending it -- it looks good, and not
too hard to integrate. BTW, I definitely owe you a MLton t-shirt.
Please send me in private email your size (M, L, XL) and address and
I'll drop one in the mail.
I have a few issues I'd like to bring up on the list before I start in
on some of the stuff. Nothing major, though. Assuming all goes well,
I plan to get the code in this week.
* I think the name of the MLton.Platform.OS.t variant should be
"MinGW", not "Mingwin". We try to stick with whatever name the
project uses for itself.
* For the x86 codegen, we no longer use reserveEsp for Cygwin. I
don't think there's any need for it on MinGW either. Did you put it
there for a reason or just to mimic the Cygwin case?
* 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
* In the C #ifdefs, sometimes you use __MINGW32__ and sometimes
__MSVCRT__. Is there a method to what you did, or could they all be
replaced with __MINGW32__?
* Why did you include win32-resource.h? It appears to be unused.
* I'm afraid I can't include the GPL'd code from the Labrea project
for MLton.Syslog and from Cygwin for Posix.Io.Flock, ProcEnv.uname.
Although MLton is currently released under the GPL, this is
problematic for commercial users, because their code, which links
with the MLton runtime, is also required to be GPL'd. We hope to
change our license some day, at least to include an exception for
such situations. The reason we have not done so already is that NEC
holds the copyright on the original release of MLton, which was
released under the GPL, and as yet has been unwilling to relicense.
We are still hopeful they will, though, and don't want to pollute
MLton with GPL'd code from other sources. I apologize for any
extra work this may have caused -- this information really belongs
somewhere more accessible to potential contributors.
* There are a number of functions on Windows that don't make sense (or
at least are unimplemented for now). Here's a list I compiled as I
read your patch.
There are a number of things we could do for these functions.
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
You chose (E). I think the right choice is (B). We would rather
warn users that they have called an unimplemented function than
silently continue. I think (B) is better than (D) because we have
better abstraction facilities in SML and can more concisely define
the different behavior. The reason I don't like (A) is that it
leads to conditional compilation of SML code, since we will need to
provide different versions of the basis for Windows and for Unix,
and this will lead to conditional compilation of user code as well.
Of course, we will need to document all the unimplemented functions
in the user guide. Since there are so many, and it might be
confusing to users to have just a little bit of Posix defined,
another reasonable alternative would be for us to cause all the
Posix functions to fail on MinGW. That is simpler to document and
to think about. It would encourage people to use the more portable
OS structure. One drawback is that a number of the functions work
sensibly, and we are making code that uses them harder. So, I
suspect this is a bit overkill.
Any thoughts people have on any of theses issues are appreciated.