Claus Reinke wrote:
>> It is supposed to show only free variables in the selected expression.
I'm sure I had cases when I was able to access variables which were
not free in the selected expression but which would have been in
scope if used in the selected expression. The values available seemed
correct (contrary to your case). I thought it was a step to get all
the variables in scope to be visible but later I learned it is not
feasible and my lucky experience was probably a bug. If I encounter
it again should I fill a bug report? I mean: is it really a bug?
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?
- with only the current expression and some of its free variables
accessible, I seem to be unable to use the debugger effectively
(it would be less of a problem if the current expression could
be displayed in partially reduced source form, instead of partially
defined value form)
I don't know what "partially defined value form" is. The debugger shows
the source code as... source code!
I think I know what you mean though. You want the debugger to substitute
the values of free variables in the source code, do some reductions, and
show you the result. Unfortunately this is quite hard to implement in GHCi
(but I agree it might be useful), because GHCi is not a source-level
interpreter.
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.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
