we should not be incestuous

[Henry Cejtin]

In  some  senses,  the  fact  that  the  compiler accepts things in the basis
library makes the basis library part of the  language.   I  completely  agree
with  your  suck-#1  (too  much  flexibility  in the basis library spec means
portable code is impossible to write), but that isn't the same thing  as  the
compiler  referring  to MLton.???.  I don't see any solution to this suck-#1,
but for suck-#2, I would think that the right  thing  to  do  is  to  have  a
signature   for  implementation  dependent  things,  and  a  structure  which
implements it for each compiler.  Note, the signature is invariant.  The main
point  is  that the source for this structure should ALWAYS be viewed as part
of the source.  Currently it is essentially omitted in the MLton case.   That
is, I think, bad.

You  are  right that the CM file support is another extension.  Recall that I
argued instead for a way of specifying files specific  to  MLton  and  having
another  program  to  turn them into CM files.  (This because I don't like CM
file format.)

The advantage of putting stuff in CM files is that it is clearly NOT part  of
standard  ML.   I  agree,  that  this  may  not be huge, but I think that the
advantage of making it clear what non-standard stuff must be provided is VERY
huge.

The  MLton.random  thing still confuses me: why should this be part of MLton.
You can just write it using the basis library.

Any way, that is my take on it.