could ghci debugger search for free variables better?

pepe mnislaih at
Thu Oct 23 09:01:37 EDT 2008

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.pdf
Type: application/pdf
Size: 61062 bytes
Desc: not available
Url :
-------------- next part --------------

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)


[1] -

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 at

More information about the Glasgow-haskell-users mailing list