[MLton] Implementing warnExnMatch
Vesa Karvonen
vesa.karvonen@cs.helsinki.fi
Wed, 27 Jul 2005 14:47:07 +0300
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