GHCi debugger status

[Claus Reinke]

> 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.

Isn't that a case of premature optimization? I will happily compain
about performance issues later, after the debugger turns out to be
merely too slow!-) Currently, the issue is one of it not working as 
well as it could, which seems rather more important to me (think 
of it as infinitely too slow for my needs:-). 

Once it comes to performance issues (btw, is there a debugger 
home page on the wiki, where issues/FAQs like "why can't I have 
scope contexts" are documented?), an obvious compromise would 
be to state explicitly where to preserve scope information - 
something like:

    :break fun{x,y}/{f1,f2}/f2{x}

would set a breakpoint on f2, associating with it information about 
the static scope context including only the named names (items 
between // define the path towards the name we want to break, 
level by level; additional names can be added in {} at each level), 
without affecting other parts of the program.

Claus