This limitation is annoying, I agree, but often the use of :steplocal combined with :back and :forward makes up for it (and make sure you do ':set stop :list' too). You can also use the trick of instrumenting your function with const annotations to bring into scope the variables you want, demoed by Bernie Pope in The Monad Reader issue 10, and here [1]. E.g. Suppose we have We are stopped in the highlighted subexpression, and we want to inspect variables term and text. However these are not in scope in the examined expression. We can modify the expression as follows to bring them into scope: | term == test = searchDef rest `const` (term, text) Best, pepe [1] - http://www.cs.mu.oz.au/~bjpop/papers/ghci-debug.monad.reader.pdf On 23/10/2008, at 14:34, Peter Hercek wrote:
May be my approach to debugging with ghci is wrong but in about half of the time I find ghci (as a debugger) almost useless. The reason is the limited way it can resolve identifiers. I can examine the free variables in the selected expression and nothing else. Well, I *think* just sometimes I can examine few more variables. But if it happens at all it is rare.
Is there a way to make ghci recognize all the variables which could be visible in the selected expression? By "could be visible" I mean they are in scope and can be used in the expression if I would edit the source code.
... well I would like to see the stack too but this does not annoy me that much.
Peter.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users