my experience with ghci debugger extensions

[Simon Marlow]

Hi Peter,

Thanks very much for all the suggestions here.  As Simon mentioned, we're 
not actively working on the debugger, and speaking for myself I don't plan 
to invest significant effort in it in the near future (too many things to 
do!).  If you felt like working on this yourself, possibly with Pepe, then 
we'd be happy to support in any way we can.

Peter Hercek wrote:

> /:next/ is an idea how to implement a kind of step over. That is if by 
> step over you mean something else than steplocal. The non-lazy form of 
> /:next/ forces _result and does a /:step/. The lazy form forces only the 
> top level constructor of _result before the step. Hey, I even had a case 
> when it worked just like I expected. But typically it does not work 
> because of bug #1531. _result is not correctly bound to the result of 
> selected expression in most of the practical cases. This bug is also 
> critical for all the forms of conditional breakpoints. It would be cool 
> if we could specify the condition based on _result or some part of it. 
> The implementation of ghciExt conditional breakpoints would need to be 
> extended to support conditions on _result (in particular the breakpoint 
> would need to be disabled during the condition execution) but that is 
> easy to do. Even more worrying thing about bug #1531 is that it has the 
> milestone set to _|_.

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).

Maybe there's another way to fix it, but I can't think of one right now.

Cheers,
	Simon