we should not be incestuous

[Stephen Weeks]

> Currently MLton.random does a ffi call to a C function which reads
> /dev/random.  I guess I agree with Henry that there isn't any reason that
> can't be done with the BinIO, but does raise the related question of where
> to put Linux (or more generally, OS) specific functionality.

Since we have no BinIO, I guess we can fake it with TextIO.  For now, all
extensions go in the MLton structure.

> Is  there  really  any  OS  stuff  that isn't addressed by the standard basis
> library?

Sockets, at least for now.

> Note, the random  thing  clearly  depends  on  /dev/random  (or  more  useful
> /dev/urandom)  thing  depends  on  this  file  existing  and having the right
> semantics, but I just don't see that as having any thing to  do  with  MLton.
> The  interface  to  the  GC  is a better case for things that make sense in a
> structure called MLton.

The whole idea of the MLton structure is to group together all MLton basis
library extensions in one structure to make it obvious when one is using a MLton
extension.  I could call the structure MLtonExtension, but that seems silly.  I
could create a separate substructure MLton.Random, as I have done for other
things like sockets and threads.