compilation of pattern-matching?

[Simon Peyton-Jones]

| It would be nice if we could first reach a common understanding, so
| that I can actually report the right problem, not just isolated symptoms.

It's quite simple.  The Reports specifies the semantics, not the operational behaviour. Any implementation that behaves as the Report specifies is OK.

> GHC violates that rule, as we can demonstrate:
>
>   newtype N = N Int deriving (Show,Eq)

Until this moment I believed that GHC respected the Report, and our discussion related solely to performance.  But your diligent persistence has indeed uncovered a bug. Thank you!  You deserve an accolade.

The problem you have uncovered is this.  Consider

  case (x,y) of
        (0, 'x') -> ...
        (1, 'y') -> ...
        (0, 'p') -> ...

Then it's fine for GHC to combine the two tests on 0, thus:

  case x of
     0 -> case y of ...
     1 -> case y of ...

But in doing the *combining* I also allowed the two to be *re-ordered*.  That is fine for data constructors, and it's fine if 'fromInteger' is injective, but it is NOT fine in general.

Thank you for finding this. I'll fix it.  And in fixing it I may as well arrange not to re-order constructors too, which will make you happier.  Happier, not happy, because I make no guarantees of what may happen downstream!

thanks Claus.  Since you discovered it, would you like to have the dubious honour of opening a Trac report, which I'll then fix?

Simon