Claus Reinke wrote:
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!-)
No, it's a real problem. If we retained all the variables in scope at
every breakpoint, GHCi would grow a whole bunch of space leaks. It's
pretty important that adding debugging shouldn't change the space behaviour
of the program. Of course, constant factors are fine, but we're talking
asymptotic changes here.
Now perhaps it would be possible to arrange that the extra variables are
only retained if they are needed by a future breakpoint, but that's tricky
(conditional stubbing of variables), and :trace effectively enables all
breakpoints so you get the space leaks back.
A similar argument applies to keeping the dynamic stack. The problem with
the dynamic stack is that it doesn't look much like you expect, due to
tail-calls. However, I think it would be good to let the user browse the
dynamic stack (somehow, I haven't thought through how hard this would be).
But what I'd really like is to give the user access to the *lexical*
stack, by re-using the functionality that we already have for tracking the
lexical stack in the profiler. See
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
> (btw, is there a debugger home page
on the wiki, where issues/FAQs like "why can't I have scope contexts"
are documented?)
No, please by all means start one.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
