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

[Stephen Weeks]

> The only thing I disagree with is your comment that you are unsure if a
> warning should be emitted at all.  That seems strange to me.  I definitely
> want to know about redundant matches.  What is the argument for no warning?

Page 28 of the Definition says:

  In a match of the form pat_1 => exp_1 | ... | pat_n => exp_n, the
  pattern sequence pat_1, ... pat_n should be irredundant; that is,
  each pat_j must match some value of the right type which is not
  matched by pat_i for any i < j.

In the case in question of an exception match in a functor body, there
is some value of the right type that leads to each clause.  This is
obtained by not aliasing the constructors.  So, it is arguable that
the match is irredundant.  I'm not saying it's clear one way or the
other, just that I see both sides.  I suspect that this situation is
something the Definition's authors didn't consider and so didn't say
what to do.

Clearly the following should cause a warning, since under no
instantiation can the second clause be reached.

functor F (exception E) =
   struct
      fun f() = (raise E) handle E => () | E => ()
   end