[MLton] Implementing warnExnMatch

[Matthew Fluet]

> > You don't want to use unification, because that will raise an error when 
> > the types do not unify or it will force an otherwise polymorphic type to 
> > be equal to an exception type. [...]
> 
> Yes. Although there is the function TypeEnv.Type.canUnify, which is "not
> side-effecting".

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.

> > > Actually, there seems to be some room for abstraction / refactoring. If
> > > you look for `val isBool' in `elaborate-core.fun', you'll find out that it
> > > is defined three times identically.
> > 
> > Fair enough, you might push it back as to PrimTycon and TypeEnv.Type as in 
> > the patch above.
> 
> I haven't refactored the code in this respect.

I went ahead and added this along with the rest of the patch.

> Ok. It is now applied in all of the contexts, but there are two
> special cases. 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), 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.

> In the case of
> 
>   fun f a1 ... aN = ...
> 
> the warning is disabled only if N=1 and a1 is an exception.

That makes sense.


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.