[MLton] Re: testing MLton's new front end

[Stephen Weeks]

> > dec-strdec.sml
...
> > MLton rejects B'', but not C', which the comment says must be
> > rejected, although I don't understand why it must be.
> 
> It has to be parsed as two consecutive topdecs, due to the restriction 
> stated in section 3, figure 8.

Ahh.  I missed that one thanks.  I have fixed MLton to handle this
correctly.  Feel free to throw some more tests at it whenever I do the
next release.

> > undetermined.sml
...
> > So, MLton rejects this program.  I don't have any plans to chage this
> > behavior.  I think this a point of disagreement between you and me and
> > that you believe the Definition requires the program to be accepted.
> > In any case, your table gives a MLton a "+" here.
> 
> But I don't think there is any unclarity with respect to the examples in 
> undetermined.sml. Each type is determined within a single topdec, and 
> there is nothing in the Definition that would restrict it further.

Ah, now I understand.  You are correct.  I have fixed MLton to handle
these examples.

As to the other examples where there are two topdecs, MLton now
rejects those as well.

   val a = ref nil;
   val _ = a := [1];

   val a = ref nil;
   structure X : sig val a : int list ref end =
   struct
       val a = a
   end;

It doesn't do it exactly according to section G.8.  Rather, it chooses
unique monotypes for the undetermined types that then fail to unify,
which I guess is what Poly/ML and SML/NJ do.