| 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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
