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