Should exhaustiveness testing be on by default?

[Claus Reinke]

> Here are the +RTS -xc and mapException outputs together (when I
> remove the mapError annotations, only the first <..> is printed, so
> that is the part to focus on, the rest is confusion) 

Actually, it looks as if the implementation of mapException modifies
the stack that +RTS -xc prints. Not entirely surprising, perhaps.

We can use that to illustrate the RULES for call site annotation suggestion, 
by rewriting call sites of functions to be traced to prefix 'mapException id'
(see attached source).

That won't change the error message, because the RULES don't have the 
source location we'd need there, but it will put a stack frame with lexical 
stack info onto the stack. 

On error,  +RTS -xc prints the stack frames, corresponding to a dynamic 
stack trace, each stack frame giving a lexical stack for an annotated call site.

1) no annotations, no +RTS -xc:

    $ ghc -e main stacktracesXcHack.hs

    -- fib 5
    fib with non-positive number: 0

    -- odd_ 5
    odd_: no match

    -- firstLetters2
    Prelude.head: empty list

2) no annotations, +RTS -xc only:

    $ ghc --make -prof -auto-all stacktracesXcHack.hs -DHACK
    [1 of 1] Compiling Main             ( stacktracesXcHack.hs, stacktracesXcHack.o )
    Linking stacktracesXcHack.exe ...

    $ ./stacktracesXcHack.exe +RTS -xc

    -- fib 5
    <Main.fib_,Main.main,Main.CAF>fib with non-positive number: 0

    -- odd_ 5
    <Main.odd_,Main.odd',Main.main,Main.CAF>odd_: no match

    -- firstLetters2
    <GHC.List.CAF>Prelude.head: empty list

3) RULES-based call site annotations, +RTS -xc (reformatted for readability):

    $ ghc --make -prof -auto-all stacktracesXcHack.hs -DHACK -fenable-rewrite-rules
    [1 of 1] Compiling Main             ( stacktracesXcHack.hs, stacktracesXcHack.o )
    Linking stacktracesXcHack.exe ...

    $ ./stacktracesXcHack.exe +RTS -xc

    -- fib 5
    <Main.fib_,Main.main,Main.CAF>
    <Main.fib_,Main.main,Main.CAF>
    <Main.fib_,Main.main,Main.CAF>
    <Main.fib_,Main.main,Main.CAF>
    <Main.fib_,Main.main,Main.CAF>
    <Main.fib_,Main.main,Main.CAF>fib with non-positive number: 0

    -- odd_ 5
    <Main.odd_,Main.CAF>
    <Main.even_,Main.odd_,Main.CAF>
    <Main.even_,Main.odd_,Main.CAF>
    <Main.main,Main.even_,Main.odd_,Main.CAF>odd_: no match

    -- firstLetters2
    <GHC.List.CAF>
    <Main.firstLetters2_,GHC.List.CAF>Prelude.head: empty list

Would be much better if RULES could provide source location info
from their application sites, or if at least +RTS -xc would contain
source locations (shouldn't the parameters belonging to each stack
frame be accessible, too?-). And is there an easier way to specify 
apply-once RULES than this double naming business?

But perhaps it help to illustrate the potential, both for combining
dynamic and lexical stack, and for using RULES for call site
annotations..

Claus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stacktracesXcHack.hs
Type: application/octet-stream
Size: 1379 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090528/609489a3/stacktracesXcHack-0001.obj