[MLton] MLton's adherence to the Definition of SML

[Stephen Weeks]

> I like Stephen's thoughts, but I'll point out that you occasionally mix
> adherence to the Definition of SML with adherence to the Basis Library;
...
> I see a difference between providing more
> structures than dictated by the Basis Library (i.e., an extension of the
> BL), and providing more syntax than dictated by the Definition (i.e., an
> extension of the D).

Sorry for confusing the two.  I completely agree there is a
difference.  And that difference is why we have allowed many more
library extensions than language ones.

> In addition to the points you make, the Unresolved Bugs section of the
> User's guide specifies a few additional differences.

Good point.  The three listed there are all restrictions.

> > Another difference between library extensions and language
> > extensions is that library extensions are mostly implemented outside
> > the compiler, and are hence presumably more accessible to non MLton
> > experts.
> 
> I don't agree with this as much.  If an extension is really impossible to
> support in Definition/Basis Library, then it almost certainly requires
> some compiler support.  It may be the case that a library extension can be
> implemented using just FFI, but that is just an indirect dependence on
> compiler support.

Right.  That's why I said mostly.  Not a super-strong point, but I
think it will be easier for a non MLton expert to figure out how, say,
MLton.Finalizable works than how _import works, because
MLton.Finalizable is mostly implemented in a small, self-contained SML
library, with a little compiler support, and is delivered with MLton,
whereas understanding an extension like _import requires delving into
the compiler internals, which is a much harder task.

> There is also the situation where some of the MLton. structures are really
> providing a richer interface than that specified by the Basis Library.
> There are some pragmatic concerns there as well.  For example,
> MLton.Vector.unfoldi can be implemented against the Basis Library, but the
> provided function is marginally more effcient.  Another scenario is
> MLton.TextIO, which mostly remembers some implementation details that are
> hidden away behind the Basis Library specification for TextIO.

Right.  And part of the reason we are much more willing to do this
sort of thing is that it is mostly in the library.

I guess there's also your point, which I agree with, that the Basis
Library is necessarily incomplete -- there can always be more
libraries.  People are used to that kind of change.  On the other
hand, people are (rightly) much more wary of language change.  That
also plays to the perception of potential new users.

There's also a self-fulfilling prophecy going on here.  If we
consistently allow basis extensions and disallow language extensions
over a long period of time, as we have done over more than five years,
then the kinds of users we will get are the kind that like, or at
least can live with, that kind of change.  So it makes even more sense
to our user base to continue with that policy.