GHCi debugger status

Pepe Iborra mnislaih at
Mon Nov 24 12:09:38 EST 2008

On Mon, Nov 24, 2008 at 5:28 PM, Daniil Elovkov
<daniil.elovkov at> wrote:
> Peter Hercek wrote:
>> Daniil Elovkov wrote:
>>> A refinement of :tracelocal could be :tracedirect (or something) that
>>> would save the history not anywhere within the given function but only
>>> within parents, so to say. For example,
>> This looks like what I thought of as searching for values in dynamic stack
>> (explained in my response to Pepe Iborra in this thread).
> Yes, first when I saw that your message I also thought "Hey, Peter has
> already suggested it!" :)
> But now I see that we're talking about slightly different things. Consider
> fun x y =
>  let f1 = ... (f2 x) ...   -- f1 calls f2
>      f2 = exp_f2
>  in ...
> Now, if we're at exp_f2 then 'dynamic stack' in your terminology includes
> (f2 x) since it's the caller and all f1 as well.
> On the other hand, :tracedirect that I suggested would not include f1, as
> it's not a direct ancestor. And for the purpose of binding variables which
> are syntactically in scope, it is indeed not needed. :tracedirect would be
> sufficient.
> Also, I think that :tracedirect can be easily implemented based only on
> simple syntactic inclusion relation.

I am not convinced this would not imply the same problems as simply
storing all the variables in scope at a breakpoint.
Consider this slightly more contorted example:

fun x y =
 let f1 = ... (f2 x) ...   -- f1 calls f2
     f2 x = x * 2
 in case x of
     1 -> f2 0
     _ -> f2 (f1 y)

g x = let z = (some complex computation) in z `div` x

main = print (g (fun 1 2))

This is a classical example of why laziness gets in the way of
debugging. Now, when (f2 0) gets finally evaluated and throws a
divByZero error, x and y are nowhere to be found.
Since we do not have a real dynamic stack, it is difficult to say
where their values should be stored. The only place I can think of is
at the breakpoint itself, but then as Simon said this poses a serious
efficiency problem.

More information about the Glasgow-haskell-users mailing list