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
    <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]"	merge	closed	normal	6.10 branch	Compiler	6.11	wontfix			Unknown/Multiple	Unknown/Multiple		Unknown	deSugar/should_run/T3126