[MLton] Windows port of MLton using the Microsoft tools (e.g.without MinGW)

[Nicolas Bertolotti]

> > Why does Mlton need any "Unix-ish" code? It's a language translator,
> > the bulk of the compiler should be entirely platform independent.
> 
> Well, sure, it doesn't NEED to be Unix-ish, but it is. The path of
> least resistance is to leave it that way. However, I didn't realize
> that Nicolas had already gotten it to a more-or-less working state.
> If someone actually *wants* to make it work with a MS compiler, good
> luck to them! I will still use the MinGW port, though, because that
> compiler is free and is less effort when I port from unix.
> 

I think I don't like Windows and the Microsoft compilers more than you do.
Anyway, my approach is pragmatic. If I can manage to get a working native
port that is a preliminary step to a working 64 bits version that is
available before MinGW, I'll take the opportunity.

> > Windows has more advanced dynamic linker support than Unix
> 
> I'm not sure whether to laugh or cry.
> 
> Windows decided that it couldn't fix it's broken dynamic link
> libraries, so switched to what amounts to static linking. I'm sure MS
> wants us all to believe this is a better model, but there's many
> reasons it's not (a bug in the library, anyone?). Unix has had
> working libraries for ages, and no one talks about replacing them,
> because the model actually works. I suppose it's easier to install
> applications if you don't need to track down libraries, but package
> management systems solved this years ago.

Agree ... In my point of view, Windows contains the same design errors than
Multics, that is an operating system and its API is definitely too complex. 

When you want to do something simple with Unix, you just do it. When, you
want to do something simple with Windows, you have to write 50 lines of code
using some very complex API functions (ever tried to write a piece of code
which sets the owner and permissions of a file ? I had to do it => 150 lines
of code).

> 
> > So whilst Mlton likes to mess about with very high performance low
> > level optimisation
> 
> I believe the opposite is true. MLton's "low-level" optimizations are
> terrible! Most of the speed-up comes from much earlier optimizations.
> I was quite hopeful when there was talk about MLton+LLVM.

Agree again ... The only example of compiler I know which is "really"
platform independent is ... Java ... and I guess nobody will say that it is
an example to follow when you want to get a binary that runs as fast as
possible. You can try to write a compiler that abstracts as many things as
possible. Then, you'll also have to accept that the performances are not as
good as they could be without this constraint.

The "real" system dependencies there are in MLton are located in the runtime
system and in the native code generator. I don't think this is really so
strange.

> 
> 
> _______________________________________________
> MLton mailing list
> MLton at mlton.org
> http://mlton.org/mailman/listinfo/mlton