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

[Andreas Rossberg]

Hi,

> ----------------------------------------------------------------------
> abstype2.sml
> 
> I agree it is a bug that MLton 20040106 accepts this program.  I think
> this bug will probably stay, though, since fixing it would cause
> problems (seen in all the other compilers except Alice) with
> abstype.sml.  I think it is better to err on the side of mistakenly
> accepting a few corner cases rather than mistakenly rejecting a few
> corner cases.

Fully agreed. In any case, I consider the spec of abstype plainly broken 
with respect to equality.

> I guess this is what you chose for Alice too?

Well, Alice currently simply ignores eqtypes. That's also the reason why 
it accepts abstype.

> ----------------------------------------------------------------------
> dec-strdec.sml
> 
> Here's what MLton 20040106 reports.
> 
> Error: dec-strdec.sml 49.13: function applied to incorrect argument
>    expects: [int]
>    but got: [real]
>    in: double 2.0
> compilation aborted: elaborate reported errors
> 
> 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.

> ----------------------------------------------------------------------
> fun-case.sml
> 
> Here's what MLton 20040106 reports.
> 
> Error: fun-case.sml 8.14: syntax error: replacing  EQUALOP with  DARROW
> compilation aborted: parse reported errors
> 
> I have no idea how to get this one right :-(.

Heroic grammer transformation hacks plus some post processing :-). Not 
worth it, I guess (although I really find this one a frequent nuisance 
in practice).

> ----------------------------------------------------------------------
> redundant.sml
> 
> Here's what MLton 20040106 reports.
> 
> Warning: redundant.sml 10.1: function has redundant rules
>    rules: f F = 2
>    in: f E = 1 | f F = 2 | f _ = 0
> Warning: redundant.sml 16.32: handler has redundant rules
>    rules: F => ()
>    in: ((raise (E))) handle (E) => (()) | (F) => (())
> 
> MLton is the only SML compiler I have that reports an warning on line
> 16, but I'm not clear on what the Definition requires for matches
> inside functors where there is potential aliasing of exception
> constructors.  Section 4.11, page 28, point 2, says that a warning
> must be issued if the match is redundant.  But if the functor is never
> applied, then is the match redundant?  What if the functor is applied
> to some structures where the exception constructors are aliased, and
> other structures where they are not?  Then, the match is clearly not
> redundant, unless you consider different duplicates of the functor
> body (which is what MLton does).

I thought the check was performed at application point (although the 
error location given might be a bit confusing). And indeed MLton does 
not complain when I remove the functor application. MLWorks used to do 
the same thing. It seems to be a good strategy, although it does hardly 
scale to separate compilation.

I'm not sure whether a compiler should warn about any *potential* 
redundancy. This would make exceptions as functor arguments pretty 
noisy, I guess.

> ----------------------------------------------------------------------
> replication.sml
> 
> Here's what MLton 20040106 reports.
> 
> Error: replication.sml 6.23: attempt to replicate non datatype: u
> Error: replication.sml 18.27: attempt to replicate non datatype: u
> compilation aborted: elaborate reported errors
> 
> Nevertheless, your table reports "+".  I believe that this program
> should be accepted and have checked in a fix to do so.  So, your "+"
> will be right for our next release.

Right, I have to admit that I was pretty busy and hence did not check 
all programs, but mainly those that didn't work before. Thanks for 
pointing this out! That should teach me.

> ----------------------------------------------------------------------
> undetermined.sml
> 
> Here's what MLton 20040106 reports.
> 
> Error: undetermined.sml 10.5: unable to infer type for a
>    type: ??? list ref
>    in: val a = ref nil
> Error: undetermined.sml 8.15: variable type in structure disagrees with signature
>    variable:  a
>    structure: [unit] list ref
>    signature: [int] list ref
> Error: undetermined.sml 15.5: unable to infer type for a
>    type: ??? list ref
>    in: val a = ref nil
> compilation aborted: elaborate reported errors
> 
> 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.

I remember we had a discussion about whether examples like

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

or

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

(where there are two distinct topdecs) have to be accepted. The 
intention of the side conditions in rules (87) and (89) is to reject 
such examples (although they fail to do so formally).

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.

> ----------------------------------------------------------------------
> valrec.sml
> 
> Here's what MLton 20040106 reports.
> 
> Warning: valrec.sml 6.5: declaration is not exhaustive
>    missing pattern: 0
>    in: 1 = x 1
> unhandled exception: Fail: should not get here!
> 
> I understand what the Definition says on this one, but MLton, at least
> in 20040106, allows the rebinding of constructors with val rec.  So,
> for now, this should be a "-", not a "+".  I will think about whether
> and how to make MLton conformant.

I wouldn't bother, actually. I consider it a bug on the side of the 
Definition.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.