#3126: GHC needs to be more careful about pattern match order
-----------------------------+----------------------------------------------
Reporter: claus | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.11 | Severity: normal
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-----------------------------+----------------------------------------------
The [http://haskell.org/onlinereport/exps.html#sect3.17.2 language report]
specifies pattern match order to be sequential, left-to-right, out-in,
top-down. It explicitly allows for different implementations, as long as
the differences are not observable and certain
[http://haskell.org/onlinereport/exps.html#sect3.17.3 rules] remain valid.
One such rule is:
{{{
case e of {p1->e1;p2->e2} =
case e of {p1->e1;_->case e of {p2->e2;_->error "No match"}}
}}}
GHC invalidates this rule:
{{{
newtype N = N Int deriving (Show,Eq)
instance Num N where
fromInteger 0 = error "0"
fromInteger 1 = N 0
fromInteger _ = N 1
f x = case x of
1 -> False
0 -> True
g x = case x of
1 -> False
_ -> case x of
0 -> True
_ -> error "No match"
main = do
print $ g (N 0)
print $ f (N 0)
-- ghc
$ ghc -w -e main PMOrderSpec.hs
False
<interactive>: 0
-- hugs
Main> main
False
False
}}}
The same effect can be achieved via `Data.String.IsString` (see attached
test case).
See also:
- [http://www.haskell.org/pipermail/glasgow-haskell-
users/2009-March/016949.html compilation of pattern matching?]
- [ticket:246 Wrong pat-match order for records]
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3126>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
