[MLton] Implementing warnExnMatch

[Matthew Fluet]

> > > In the case of
> > >   val p1 = e1 and ... and pN = eN
> > > the warning is disabled only if all bindings are of exceptions. 
> > 
> > The situations in which the warning is disabled seems sufficiently rare
> > (and of dubious use),
> 
> I have no idea of the general statistics, but I use `and' quite rarely,
> so warnExnMatch would probably be applied almost always (when the binding
> is of type exn --- although that is likely to be very rarely).
> 
> > that I wonder if it isn't better to not apply the warnExnMatch annotation
> > here.
> > 
> > Also, I note that an inexhaustive match in this situation leads to a Bind 
> > exception, rather than a Match exception.
> 
> True. However, warnMatch (rather than a hypothetical warnBind) annotation
> was already applied to the case, so applying warnExnMatch isn't totally
> inconsistent. At any rate, this case is unlikely to make a significant
> practical difference and I have no major argument either way.

I agree that it makes little practical difference.  And I guess that is 
reason enough to leave it consistent.

> > Finally, I'll note that you do not get any warning about the redundant 
> > pattern in the following case:
> > 
> >   val rec cause = fn Rec exn => cause exn | Rec exn => cause exn
> > 
> > So, that suggests that it will be best to compile with 'warnExnMatch true'
> > to look for redundant pattern warnings and then compile with 'warnExnMatch
> > false' to avoid inexhaustive pattern warnings.
> 
> Ouch... I didn't notice that mayWarn also disables redundant rule warnings.
> Are there actually truly plausible situations under which someone would want
> to have redundant rules? 

Probably not.  I will note that SML/NJ raises a hard error in the case of 
a redundant rule, so it is not even possible to compile code with 
redundant rules.  (But, this is a deviation from the Definition.)  The 
MLKit gives a warning.  HaMLet does not give a redundant match warning. 
MoscowML gives a warning.

> I can imagine that someone might systematically use
> a wild pattern in the last rule, thinking that it improves the robustness of
> the code, but I wouldn't call it plausible, because SML compilers give warnings
> for redundant rules (unless instructed otherwise). Another case might be a
> code generator of some kind, but it would seem rather dubious to generate
> redundant rules. Would it be better to always give a warning for redundant
> rules?

I'm tempted.  

However, one reason for adding the warnMatch annotation was that it made
it possible to wrap up a body of code and essentially insulate yourself
from that programming style.  For example, I use 'warnMatch false' in the
MLB files for the SML/NJ Library, because it has a number of inexhaustive
matches, but, believing that it is relatively bug-free, I don't want to be
bothered by them anymore.  More importantly, I don't need to go in and 
modify any of the code.

But, it does seem as though redundant matches are a truly rare occurrence.
I can't recall seeing any in released code, whereas inexhaustive matches 
are a common occurrence.