[MLton] Implementing warnExnMatch

[Vesa Karvonen]

Thanks for applying the patch! I can now simplify my test code.

Quoting Matthew Fluet <fluet@cs.cornell.edu>:
[...]
> Good point, but I think Type.isExn is better.  TypeEnv.Type.canUnify might 
> return true, but later return false, while Type.isExn will always return 
> the same boolean.

Yes. That is basically what I also thought. (I have previously implemented
a type inferencer (as part of a very simple compiler) for an ML-style
language.)

> > 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.

> 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? 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?

-Vesa Karvonen