[MLton] cvs commit: new front end

[Matthew Fluet]

>   I am beginning to wonder if using the :> for Basis2002 is the right
>   approach.  The problem is that this approach introduces lots of
>   potential bugs where we reject valid programs because two types are
>   not equal that should be, because we haven't added the appropriate
>   sharing or where.  If instead we were to use :, then we might accept
>   some programs because two types are equal that shouldn't be.  But that
>   seems more benign.  And when we learn it, we can use a :> somewhere
>   earlier in the basis library code to patch stuff up.  Although maybe
>   it's just a question of how quickly we can get to a correct BASIS_2002
>   so that the single big :> works.

I would vote for keeping :> and push the sharing and opacity back to the
roots of the problems.  Although accepting more programs than we should
with : might appear more benign, I think it is the wrong upgrade path.
Users will (rightly) complain when things aren't equal that should be, but
probably won't when the type-checker is too forgiving.  And if from one
version of MLton to the next, a user's program is rejected, then they
might just stick with the older compiler; wheras if a user's program is
accepted by the new compiler, then they will move forward.

Certainly we have to fix the leaking of slice representations; the
correctness of the implementation relies on programs not being able to
forge invalid slices.

I guess the final question is whether or not we need any magic in
BASIS_2002 -- that is, whether or not there really is a valid SML program
where we can get all the opacity and sharing correct to match the Basis
specification.