GHCi debugger status

[Peter Hercek]

Simon Marlow wrote:
> Peter Hercek wrote:
>> Simon Marlow wrote:
>>> A similar argument applies to keeping the dynamic stack.  The problem 
>>> with the dynamic stack is that it doesn't look much like you expect, 
>>> due to tail-calls.
>>
>> Do you think people expect the tail-calls to add a stack frame to the 
>> dynamic stack or is there something more complicated?
> 
> Right, I think they expect exactly that, and it'll confuse people that 
> some stack frames are "missing".  Often it's not clear which calls are 
> tail-calls and which are not.  Mind you, I think the fact that it's a 
> dynamic call stack rather than a lexical call stack is likely to confuse 
> the same set of users even more.

That is a good point, I might not see at the first look whether it is a 
tail call or not. Which reminds me that if it is implemented the way I 
expected then stack frames which are tail calls should be marked that 
way so that it is possible to see at the first look whether the given
stack frame is a tail-call or not.

If it will be a lexical call stack I'm curious how the pruning will be 
done so that we do not miss stack frames when we return from some code 
which corresponds to an imperative loop. Maybe a top limit on the number 
of stored lexical frames in one imperative (call-recursive) frame? From 
my point of view this could work well enough if it can print something 
like "and here there were some lexical frames pruned and we are going 
one dynamic frame higher".

My reasons why I want to see it with tail-calls collapsed into one stack 
frame is that I need debugger to figure out why something does not work 
so I should see what it looks like close to the execution model where 
the bugs actually present themselves. I believe that collapsed 
tail-calls is not such a big deal if there is a way to filter trace 
history (like tracelocal idea or something similar) or maybe having a 
really long trace history. Hmmm, maybe it would be even possible to 
recover last part of the lexical stack from the dynamic stack and the 
trace history.

I discussed a bit with Pepe Iborra about how to build the dynamic (lazy) 
stack from a trace on the fly. Something like whenever we reduce an 
expression we would prune the corresponding node in the trace. Such a 
pruned trace should correspond to the dynamic stack. (If I do not miss 
something which I probably do.) And moreover if we record the 
expressions (their source code range) we just pruned and the result they 
  reduced to then we can show it with some command like 
:showexpressionresults. This would provide access to unnamed values 
which could have been sent to a lower level calls as inputs. And that is 
  part of the problem we discussed in this thread.

Anyway thank you, Clause Reinke and Pepe Iborra for all the great help 
with ghci ... I'm still learning how to script ghci debugger better. I 
hope I can make it better than "printf debugging" with the scripts :-)

Peter.