﻿id summary reporter owner description type status priority milestone component version resolution keywords cc os architecture failure difficulty testcase blockedby blocking related 3126 GHC needs to be more careful about pattern match order claus "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 : 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]" merge closed normal 6.10 branch Compiler 6.11 wontfix Unknown/Multiple Unknown/Multiple Unknown deSugar/should_run/T3126