[MLton] extended basis library

[Stephen Weeks]

> Right, it is exactly the stuff in basis.mlb that really confused me for a bit
> because I couldn't see what
> 	val x = x
> could possibly do.

It wouldn't be necessary to drop down to SML to do such things if we
had added valdecs to the list of allowed MLB declarations:

  val <id> [= <id>] (and <id> [= <id>])*

I guess we chose not to out of some kind of economy, since it can be
done in SML.  But looking at it now, it seems reasonable to add (note
that the right-hand side is just an id, not a full expression).  Ditto
for types, datatypes and exceptions, I guess.

The syntax/semantics for vals is obvious, I think.  But there are some
issues for types.  Would we require type arity to be specified as in
SML:

  type 'a t

I think that is the wrong way to go, and inconsistent with what we do
for everything else (why specify the kind of types, if we don't
specify the type of values or the signature of structures, or ....).
Similarly, I think rebinding of types should not follow the (ugly, to
my eye) SML syntax that requires one to duplicate the arity specs.
So, for a unary type constructor one should write

  type t = u

and not

  type 'a t = 'a u

The issue with datatypes is whether a type binding exposes the
constructors or whether we require a separate syntax (like SML).  I
think that the latter makes sense, so that one must write

  datatype list

to export the list type constructor and its constructors, while

  type list

would export only the type constructor.

As to exceptions, the syntax is certainly confusing because of the
conflict with SML, but the logical analog of what we've done is to
have

  exception E

mean, effectively, 

  exception E = E

That is, an exception is not being constructed, only exposed.

Maybe exceptions and types require some more thought and discussion,
but I think that values may be uncontroversial.  What do people think?

> I just think that this kind of hiding would make more sense to be in
> the file.  The argument against this (which is certainly not weak)
> is that as things are, the non-mlb files really are pure standard
> ML.

That is one argument.  But I think that cross-file local is actually
useful on its own merits.