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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
