[MLton] VC++ as the C compiler for MLton? (Was: Compiler dependencies)

Stephen Weeks MLton@mlton.org
Tue, 29 Jun 2004 21:35:06 -0700


> The steps which have been done is to port MLton between UNIXen, and
> to port it to the Cygwin platform (If I am not mistaken).  

Right.

> This i see as a very good thing, religious war or not. By porting,
> you usually uncover bugs and problems, which were otherwise
> unknown. You uncover differences in implementations of standard
> libraries and things like that. Very important things to get solved.

I agree.  I think the porting, both to new OSes and new architectures,
has been very beneficial in many ways.

> As for the general portability of MLton we could use a bit of
> restructuring in the C runtime, not far away from what John Reppy
> did in SML/NJ: Building an abstraction layer of features, which the
> different UNIXen then enable, disable or overrides.

There's certainly some room for improvement, but I don't see a whole
lot of room here.  There are some ifdefs to get the include files
right, and then some to handle the way memory management works on the
different UNIXen, and then a couple more for signal handling and
profiling.   But that's it.

> But a bit more abstraction than what is inside the runtime now could
> be used, if there is a plan to port to more architectures that is.

There certainly is.  The next platforms on the list are MinGW (if we
get some outside help) and PowerPC/MacOS X (which I hope to do this
year if no one else does).

> The caveat of such work is that it help tremendously to have access
> to all architectures supported to test the changes on. I see this as
> the main showstopper for not delegating the work.

I don't think that's a big deal.  I certainly plan to keep an instance
of each platform that MLton runs on so I can build and test all the
binary packages.  Adding new x86 OSes is cheap, since I use VMWare.
Adding a new architecture like PowerPC costs, but is not prohibitive.