[MLton-user] The SML basis library socket module

[Stephen Weeks]

> You mean the different basis library implementations are not
> interchangable across the various SML compilers?

Right, due to bugs, moving targets, and freedoms allowed by the
specification.

> Isn't interchangability exactly the point of having a standard basis
> specification?

Yes.  We're all working toward it.  But it's not perfect.  It's not
all that bad either.

> Or maybe you are refering to the Mlton and Smlnj structures?

No.


There are three moving targets: the basis library spec, the SML/NJ
basis library implementation, and the MLton basis library
implementation.  They move at different rates, and hopefully are
converging, but aren't there yet.  So, whenever I develop SML code
with both MLton and SML/NJ, I assume that the basis libraries are as
whatever the current MLton has, and use stubs to make SML/NJ's library
look like MLton's.  The stubs handle missing, type incorrect, or buggy
stuff from SML/NJ.

Once the basis libraries converge, there will still be differences due
to aspects of the basis library that are allowed to change across
implementations.  For example, in MLton, Int.precision = SOME 32,
while in SML/NJ, Int.precision = SOME 31.  You're not likely to notice
this in a lot of programs, but in some (like compilers) you will.  So,
a lot of the stubs deal with modifying the SML/NJ basis library to
make Int = Int32.  Of course, there is a performance penalty for this,
but I don't care since I always compile stuff that I want to run with
MLton.