[MLton] Implementing warnExnMatch
Matthew Fluet
fluet@cs.cornell.edu
Wed, 27 Jul 2005 08:33:53 -0400 (EDT)
> > > 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.