GHCi debugger status

[Peter Hercek]

Simon Marlow wrote:
> Claus Reinke wrote:
>> Perhaps someone could help me to understand how the debugger is 
>> supposed to be used, as I tend to have this problem, too:
>>
>> - when I'm at a break point, I'd really like to see the current scope
>>    or, if that is too expensive, the next enclosing scope, in full
>>    (not only would that tell me what instantiation of my code I'm in,
>>    it would also seem necessary if I want to reconstruct what the
>>    current expression is)
> 
> I don't understand what you mean here - surely in order to "reconstruct 
> what the current expression is" you only need to know the values of the 
> free variables of that expression?  Also I don't understand what you 
> mean by the "next enclosing scope".  Could you give an example?

Maybe what Claus means is that he would like to see the dynamic
  stack and be able to traverse it and at each location in the
  dynamic stack he could investigate the free variables in the
  expression (corresponding to the dynamic stack slot). I actually
  considered this as a feature request but I decided that I would
  like to have this implemented sooner:
http://hackage.haskell.org/trac/ghc/ticket/2737


>> Currently, I only use the debugger rarely, and almost always have to 
>> switch to trace/etc to pin down what it is hinting at. What is the 
>> intended usage pattern that makes the debugger more effective/
>> convenient than trace/etc, and usable without resorting to the latter?
> 
> Set a breakpoint on an expression that has the variable you're 
> interested in free, and display its value.  If your variable isn't free 
> in the expression you want to set a breakpoint on, then you can add a 
> dummy reference to it.

Actually I use it a bit differently mostly because I know
  (or I'm guessing) where the bug is located and set a breakpoint
  at a place which is hit just after the wrong decision happens.
  The "just after wrong decision" requirement is there so that
  I do not need to have too complicated expressions in the
  conditional breakpoint. Then I count how many times the
  breakpoint is hit of find some other expression which is
  true just before the hit I'm interested in (the hit with bug).
  I modify the script of the breakpoint so that it stops just
  before the hit I'm iterested in and restart. After restart
  the debugger stops at the modified breakpoint and I continue
  with either :steplocal or :trace. This is so that I have
  values of previous expressions in the trace history. Then
  (If I used :trace) I check the values in the trace history
  to find out why I got at the wrong place.

The procedure is quite complicated but I do not know about
  quicker way to position the debugger at the right place
  and with the right variable values caught in the trace
  history.

If I would not know the approximate location of the bug
  then hpc can help.

For more simple things "printf debugging" is just enough.

Peter.