case expressions/transfers

[Stephen Weeks]

> Technically, I think this is an invalid input program because of the
> redundant cases in the definitions of toString1 and x, but MLton accepts
> it.

It is a valid program.  The Definition (page 28) says that a warning
must be issued for redundant matches, but must still compile them.

> Easy enough to fix in removeUnused by doing a real exhaustiveness
> check, but the numerical comparision would be cheaper.)

If we make exhaustive and irredundant invariants, then removeUnused
won't have to check.

> But, that's not my main point.  Something before closure conversion
> simplifies the definition of x to remove the redundant branches (and
> inserts the default branch to raise a Match exception), but the
> corresponding simplification is not performed on the definition of
> toString1.  Is there a reason why?  A reason not to?

This all happens in type-inference/match-compile.fun.  I thought that
the code was supposed to eliminate redundant branches for both
constructors and consts, but you're right, it isn't for constructors.
I am investigating.