Should exhaustiveness testing be on by default?

[Simon Marlow]

On 28/05/2009 15:09, Claus Reinke wrote:
>>> 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.
>
> Given the source locations, the lexical _position_ is obvious,

You mean the call site?  Yes, most methods will point you to the call 
site, since the top element of the dynamic stack is often the same as 
the top element of the dynamic stack (but not always).  The call site on 
its own is often not enough, however - it's just one level of the stack.

> so for mere
> traces, dynamic seems to be the choice (with an option of pseudo-cbv
> or the real dynamic stack).

I don't know what pseudo-cbv is.  And I claim the dynamic stack is 
almost never what you want.

Ok, so there's one place you might want to see the dynamic stack: when 
catching exceptions raised by pure code.  Then it really makes a 
difference whether something is evaluated or not, and you need a handle 
on the demand context in order to find out why an exception was raised. 
  On the other hand, I think this case is relatively rare compared to 
cases of the form "finding out why my program called head []".

> What is neither obvious nor provided (dynamic
> or static, in any of the proposed stack traces) are the parameters for the
> stack. If those are available, as in a debugger, the balance might shift to
> favour lexical stack, especially if I'm investigating "what is there?",
> rather
> than "who asked for this, and why?", "where am I?" or "how did I get
> there?".

Sure, providing access to free variables is certainly desirable, but I 
think it's an orthogonal issue.  There are engineering difficulties, 
such as introduction of space leaks.

> 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) - they seem to
> complement each other (-xc has no locations, but names for the
> lexical stack; mapError has no names, but locations for the dynamic
> stack; we're still missing the parameters for either stack):

I'm not claiming that +RTS -xc in its present form is what you want. 
I'm interested in finding an underlying mechanism that allows the right 
information to be obtained; things like source locations and free 
variables are just decoration.

Now, most of the existing methods have problems with CAFs.  I doubt that 
the problems with CAFs are fixable using the source-to-source 
transformation methods, but I think they might be fixable using 
cost-centre stacks.

Cheers,
	Simon