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

[Jesper Louis Andersen]

Quoting Brandon J. Van Every (vanevery@indiegamedesign.com):
> 
> Yes, but refusing to virally invade their platform with superior open
> source technologies is conceding strategic defeat.  If one is not
> willing to make concessions to industrial relevance, one isn't going to
> gain any converts.  It's not realistic to think that the world is going
> to discover the 'brilliance' of MLton or Cygwin or MinGW on their own
> merits.  Because frankly, from a get-it-done standpoint, such tools
> often lack merits.  'Support' is this nasty issue that lotsa people
> don't want to be sullied with, because it's really boring work.
> Nevertheless, it is what causes working programmers to shift from one
> technology base to another.
> 

I am quite sure this was not the intent originally. If this is a religious
war, then maybe, but I do not think that it is. The current state is
that most of the runtime is centered around UNIX Operating systems of 
different flavors. However nothing, apart from lack of willingness, hinders
a build by VC++ I think. 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).

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.

That the VC++ path is not attacked by me for instance is due to some
consequences of personal hinderance. Being a student, I do not have the
time, nor the economy to start such a project. But most importantly,
my zealotry leads to a situation where I have not had a Windows computer
for about 5 years. 

This will not hinder other people though. And if the requests were numerous
enough, I would expect to see a port. Unfortunately, I have not seen such
requests yet. Furthermore, Microsoft does not deliver something which looks
like an usual POSIX environment as far as I know (please say I am wrong, I
would love it) -- that will make it harder to port.

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. I was considering Autotools, but seeing their general
state and how irritating they are to work with, I am not much in for using
such tools. After all, I do not see any of the odder platforms Autotools 
support get support from MLton anytime soon so the benefit is not worth
the cost in my opinion. 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. 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.

For SML generally, we have SML.NET which compiles to the CIL in the .NET
framework. While the CIL does not give you the perfect framework for
running functional languages, it might be a better way if you want to
have the ''generic masses'' embrace SML. MLton is, after all, a rather
specialized compiler, doing whole-program compilation with the advantages
and disadvantages this aproach results in.

-- 
j.