Should exhaustiveness testing be on by default?
Simon Marlow
marlowsd at gmail.com
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:
>> http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
>
> 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
compiler.
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.
Cheers,
Simon
More information about the Glasgow-haskell-users
mailing list