Pattern match failure leads to lots of output
Hi, Sometimes I get a pattern match error, with output such as: pattern match failure: uniqueHite_v9935 (instEq_v280 (instEq_v20 instEq_v11) (instEq_v20 instEq_v11)) (map head [[]] ++ (map_v810 (map (uniqueHite_v9931 (instOrd_v21 instOrd_v12))) (mapMaybe (uncurry equalGiven) (map_v810 (IFunc_Func "map~1" [0] (IExpr_Case (IExpr_Var 0) [("[]",IExpr_Make "[]" []),(":",IExpr_Make ":" [IExpr_Apply (IExpr_Lambda [1] IExpr_Unknown) [IExpr_Sel (IExpr_Var 0) "hd"],IExpr_Call "map~2" [IExpr_Sel (IExpr_Var 0) "tl"]])]) [],) (_SEL (,) (select_v1958 (foldr (select (groupSetExtract_v7750 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq_v481 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq_v481 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq_v481 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq_v481 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq_v481 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq_v481 (Make.Eq (instEq_v20_v1493 instEq_v11) (Eq ... Where the output goes on forever. This is unfortunate, because having sped up the screen printing of WinHugs quite considerably, now its a race to hit the stop button before this stuff has taken up the whole screen buffer (100Kb) and pushed the name of the function causing the error off the top. I guess the cause of this error is dictionary transformations resulting in a nested dictionary? Is there any way to stop this happening? Is it a known bug - it happens reasonably regularly to me. Thanks Neil
On Fri, Sep 01, 2006 at 04:40:09AM +0100, Neil Mitchell wrote:
Sometimes I get a pattern match error, with output such as:
pattern match failure: [...]
Where the output goes on forever. This is unfortunate, because having sped up the screen printing of WinHugs quite considerably, now its a race to hit the stop button before this stuff has taken up the whole screen buffer (100Kb) and pushed the name of the function causing the error off the top.
I guess the cause of this error is dictionary transformations resulting in a nested dictionary? Is there any way to stop this happening? Is it a known bug - it happens reasonably regularly to me.
It would probably be better to hide the dictionary arguments and the _vNNN suffixes altogether in pattern match errors. Can you put a boiled-down example in the BTS?
Hi
It would probably be better to hide the dictionary arguments and the _vNNN suffixes altogether in pattern match errors. Can you put a boiled-down example in the BTS?
Here is a small failing example, with context and stuff its hard to know when I get it minimal:
data Maybe1 a = Just1 a | Nothing1 deriving Eq data Maybe2 a = Just2 (Maybe1 a) | Nothing2 deriving Eq crash_me = g (Just2 (Just1 1)) g x = f Nothing2 where f y | x == y && False = undefined
Run crash_me to see a lot of output. Ross: I can't test the code you sent me right now, since I'm on a machine without a C compiler, but should be back by Wednesday. Thanks Neil
On Fri, Sep 01, 2006 at 05:41:44PM +0100, Neil Mitchell wrote:
Here is a small failing example, with context and stuff its hard to know when I get it minimal:
data Maybe1 a = Just1 a | Nothing1 deriving Eq data Maybe2 a = Just2 (Maybe1 a) | Nothing2 deriving Eq crash_me = g (Just2 (Just1 1)) g x = f Nothing2 where f y | x == y && False = undefined
Run crash_me to see a lot of output.
OK, that gives: pattern match failure: g_v1624 (Num__sc0_Num instNum_v32) (Maybe2_Just2 (Maybe1_Just1 (Num_fromInt instNum_v32 1))) Maybe2_Nothing2 after my patch: pattern match failure: g (Just2 (Just1 (fromInt 1))) Nothing2 which is almost readable. Maybe I should hide fromInt/fromDouble too.
Hi
OK, that gives:
pattern match failure: g_v1624 (Num__sc0_Num instNum_v32) (Maybe2_Just2 (Maybe1_Just1 (Num_fromInt instNum_v32 1))) Maybe2_Nothing2
Before any patches? For me with the May 2006 WinHugs, that gives output forever.
after my patch:
pattern match failure: g (Just2 (Just1 (fromInt 1))) Nothing2
which is almost readable. Maybe I should hide fromInt/fromDouble too.
the fromInt would be nice to be hidden, but not really a problem. The one thing I don't like about that simplification is that g_v162 -> g. When I see g_v162 thats kind of vague, but its definately saying "a child of g" - as I read it. Now you loose the distinction between g and child of g. What would of course be lovely would be g_f, for cases where g has a named inner function that is crashing. I'm not sure how much work that is to add though. Even better would be a stack trace (showing the equivalent strict stack trace), but I realise thats probably a large change :) Thanks Neil
On Fri, Sep 01, 2006 at 11:00:27PM +0100, Neil Mitchell wrote:
OK, that gives:
pattern match failure: g_v1624 (Num__sc0_Num instNum_v32) (Maybe2_Just2 (Maybe1_Just1 (Num_fromInt instNum_v32 1))) Maybe2_Nothing2
Before any patches? For me with the May 2006 WinHugs, that gives output forever.
How odd. That's what I get with Mar 2005, May 2006 and my build from last week. The difference will be hidden if we stop printing dictionaries, but it is a bit disconcerting.
after my patch:
pattern match failure: g (Just2 (Just1 (fromInt 1))) Nothing2
which is almost readable. Maybe I should hide fromInt/fromDouble too.
the fromInt would be nice to be hidden, but not really a problem.
It's probably too much trouble.
The one thing I don't like about that simplification is that g_v162 -> g. When I see g_v162 thats kind of vague, but its definately saying "a child of g" - as I read it. Now you loose the distinction between g and child of g.
Yes, I went too far there -- now undone.
What would of course be lovely would be g_f, for cases where g has a named inner function that is crashing. I'm not sure how much work that is to add though.
So far we've been using what's in the Hugs runtime structures, and that doesn't include the names of inner functions.
Even better would be a stack trace (showing the equivalent strict stack trace), but I realise thats probably a large change :)
What's happening is that pattern match failure throws a PatternMatchFail exception (from Control.Exception). Hugs adds a wrapper around any expression you evaluate to catch any exception and print it. A PatternMatchFail exception has a String parameter. In a compiler, that will typically be the source coordinates of the failing match. In an interpreter, we have a representation of the expression we were trying to evaluate, so we turn that into a string (without further evaluating the expression). The stack is probably too much trouble. Note that because it's just another Exception, you can manipulate it in Haskell. You can catch, print and re-throw the exception yourself, or use mapException to add stuff to the String, etc.
How odd. That's what I get with Mar 2005, May 2006 and my build from last week. The difference will be hidden if we stop printing dictionaries, but it is a bit disconcerting.
Here are my settings: Current settings: +quAR -stgl.QwkoOITH -h1000000 -p"%s> " -r$$ -c40 Search path : -P.;..;{Hugs}\packages\* Source suffixes : -S.hs;.lhs Editor setting : -E"C:\\Program Files\\TextPad 4\\System\\DDEOPN32.EXE TextPad %s(%d)" Compatibility : Hugs Extensions (-98) Perhaps one of these is the cause? Thanks Neil
On Sat, Sep 02, 2006 at 12:44:31AM +0100, Neil Mitchell wrote:
How odd. That's what I get with Mar 2005, May 2006 and my build from last week. The difference will be hidden if we stop printing dictionaries, but it is a bit disconcerting.
Here are my settings:
Current settings: +quAR -stgl.QwkoOITH -h1000000 -p"%s> " -r$$ -c40 Search path : -P.;..;{Hugs}\packages\* Source suffixes : -S.hs;.lhs Editor setting : -E"C:\\Program Files\\TextPad 4\\System\\DDEOPN32.EXE TextPad %s(%d)" Compatibility : Hugs Extensions (-98)
Perhaps one of these is the cause?
Yes, with -98 I get infinite (presumably cyclic) dictionaries too. With the patch, I get pattern match failure: g_v1624 (Just2 (Just1 (fromInt 1))) Nothing2
participants (2)
-
Neil Mitchell -
Ross Paterson