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

[skaller]

On Thu, 2007-07-26 at 17:31 +0200, Wesley Terpstra wrote:
> On Jul 26, 2007, at 4:01 PM, skaller wrote:
> > 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.

No reason not to build with mingw gcc if you want,
it is certainly much easier to use this if you're developing
with Cygwin tools!

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

Yes, that's basically right, if I take you to be saying that
the coupling to the library version very tight: that's what
you mean, yes?

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

I agree, it has downsides.

> Unix has had  
> working libraries for ages, and no one talks about replacing them,  
> because the model actually works. 

No, actually it doesn't work, it's quite bad in practice.
I have a LOT of stuff .. installed by Debian and all .. that
just doesn't work precisely because the collection of shared
libraries used is almost impossible to get synchronised
(although there are other reasons).

Half my sound applications don't make any sounds,
two thirds of my video players can't play an mpg file.

As a developer, the Linux system is an utter disaster:
did you realise the compile time link process does not
check if symbols imported BY a shared library FROM a
shared library are actually present?? It just installs
the library name, the check is only done at load time.

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

No, they didn't solve it: they simply provide a mechanism which allows
very hard working packagers to waste heaps of time and effort
packaging code, trying to get all the dependencies right.

Unfortunately, most packages don't include tests -- Felix is
different, it actually runs a heap of unit/regression tests
as part of the build. The consequence is, many package build
fine and don't actually work, because the packagers don't
actually get to test them.

BTW: the above isn't a rant against package managers,
using Ubuntu is generally HEAPS better than upgrading
on Windows. I'm just saying I don't think that they
actually *solve* the library synchronisation problem..
that is actually done by hand by many packagers and 
if you look at the last Debian release .. well it took
over 12 months to get a working release.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net