Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Claus Reinke <claus.reinke <at> talk21.com>
Subject: Re: GHCi debugger status
Newsgroups: gmane.comp.lang.haskell.glasgow.user
Date: Monday 24th November 2008 17:41:32 UTC (over 8 years ago)
> 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
 
CD: 2ms