Should exhaustiveness testing be on by default?

Simon Marlow marlowsd at
Thu May 28 07:07:21 EDT 2009

On 23/05/2009 14:53, Claus Reinke wrote:
>> JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'.
>> It is actually mentioned on this page:
> Yes, I know, but the discussion on that page wanted to go beyond this
> (possibly triggered by your demonstration that one can go beyond plain
> SRCLOC;-), which is why GHC still has neither of SRCLOC or
> SRCLOC_ANNOTATE (apart from the various SRCLOC hacks).
> What is really frustrating is that GHC has the machinery to do this
> trivially (RULES, soon core2core phase plugins as well), only that this
> machinery gets applied when source location information is no longer
> available, so it is useless for this problem:-(
> One thing that wasn't available when this discussion was last active
> is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions'
> would be useful). For instance, appended below is the example from that
> wiki page, with entirely local transformations to add source locations
> and to use that info to augment 'ErrorCall' exceptions (we should really
> augment 'PatternMatchFail' exception messages as well..).
> $ ghc -e main callstack.hs
> <interactive>: hd: empty list
> ("callstack.hs",25)
> ("callstack.hs",21)
> ("callstack.hs",16)
> ("callstack.hs",13)

Your example is giving you the dynamic call stack.  Is that really what 
you want?  The dynamic call stack will often be quite different from the 
structure of your program, may well be surprising, and may even differ 
depending on compiler flags.

My personal preference would be to fix cost center stacks to do the 
right thing here.  Currently we have +RTS -xc which shows the call stack 
when an exception is raised, available when your program is profiled. 
Sometimes it gives odd results because it has bugs, but the idea is that 
it gives you a *lexical* call stack, which corresponds exactly to the 
code that you wrote, not the unpredictable evaluation strategy of the 

Obviously the down side of CCSs is that you have to compile your code 
and libraries for profiling, but OTOH you don't have to add any 
mapExceptions, pragmas, or other explicit annotation stuff.  And it 
could be added to GHCi by default, so when working in GHCi you could 
have full lexical call stacks for all interpreted code.


More information about the Glasgow-haskell-users mailing list