my experience with ghci debugger extensions

[Peter Hercek]

Hi Simon,

Simon Marlow wrote:
> If you felt like working on this yourself, possibly with Pepe, then 
> we'd be happy to support in any way we can.
Thanks. It may happen though it is not probable. I do not know the code 
so anything non-trivial is a significant effort and my free weekends and 
evenings are sparse :-(
If I would do anything, should it be posted here, sent to Pepe, or 
attached to the ticket?
Is it a habit to indicate in the ticket that somebody started coding it 
actually (especially if it takes longer to implement)?

> So #1531 is tricky to fix, unfortunately.  The implementation of 
> _result is a bit of a hack in the first place.  The fundamental 
> problem is that a tick expression looks like this
>
> case tick<n> of
>   _ -> e
>
> where 'e' is not necessarily exactly the same as the expression that 
> was originally inside the tick.  We are careful to maintian the 
> property that the tick is evaluated iff the original expression is 
> evaluated, but that's all.  _result is bound to e, which may or may 
> not be what you wanted.
>
> One way to fix it would be to add extra constraints on what the 
> simplifier can do with tick expressions.  I don't like the sound of 
> that because (a) I doni't know exactly what restrictions we'd have to 
> add and (b) this amounts to changing the semantics of Core (i.e. 
> changing which transformations are valid).
Ok, I did not understand this part a bit till I did not skim over
http://www.haskell.org/~simonmar/papers/ghci-debug.pdf
Maybe that paper should be mentioned on the wiki pages about debugger. 
Something like: "If you do not understand why ghci debugger is limited 
in such a strange way read this."

A breakpoint condition on _result:
My guess is that in about half of the cases I can just put them on a 
free variable on some other location just as comfortably. In other cases 
I'm out of luck :)

As for as /:next/ command:
Like Pepe indicated, I do not have idea how to do it without working 
_result and without dynamic stack. Though dynamic stack should not be 
that hard since  how otherwise could profiler count ticks for cost centers.
And dynamic stack would be great. It would create new options where to 
store lists of free variables of selected expressions :)

> Maybe there's another way to fix it, but I can't think of one right now.
If by simplifier you did not mean straight translation to core, then I 
assume you wanted to try to just skip over all the optimizations 
(simplifications?). Was it hard to do it or was the performance impact 
so bad that it was not worth the addition of a command line switch?

Thanks for reading the post about debugging, now there is at least a 
chance that it will be better once.

Peter.