[Haskell-cafe] How to debug GHC

[Frederik Eaton]

On Wed, Apr 27, 2005 at 05:15:30PM +1000, Bernard Pope wrote:
> On Wed, 2005-04-27 at 07:45 +0200, Ketil Malde wrote:
> > > [I want to know] who called who all the way from "main" to "head",
> > > because the key function is going to be one somewhere in the middle.
> > 
> > Perhaps.  I am told stack backtraces are difficult with non-strict
> > semantics.
> 
> This is true, at least for _lazy_ implementations of non-strict
> semantics.
>
> The reason is that the (graph) context in which a function application
> is constructed can be very different to the context in which it is
> reduced. 

Is it that backtraces are difficult, or just require a lot of
overhead? It doesn't seem very hard to me, at least in principle. Add
a "stack trace" argument to every function. Every time a function is
called, the source location of the call is prepended to the "stack
trace". I'm not familiar with the implementation of functional
programming languages, though.

(It seems like if the operation of GHC or GHCI could be parametrized
by an arbitrary monad, here a Reader, then transformations like the
above wouldn't be so difficult, and compiler compatibility for
debuggers wouldn't be so much of an issue.)

> Partial application of functions introduces a similar problem.
>
> This is not a problem in first-order eager languages because the
> construction of a (saturated) function application is followed
> immediately by its reduction. Thus the contexts of construction and
> reduction are the same.
> 
> Debugging tools like Hat, Freya and Buddha, "remember" the
> construction context of an application, so you can get call graphs that
> reflect the dependencies between symbols in the source code. Thus you
> can construct a meaningful backtrace etc. Actually, Hat remembers quite
> a bit more context than Freya and Buddha, but that's another story.

Are the following correct?

1. Hat requires users to restrict themselves to a certain small subset
of the standard libraries, and to use hmake

2. Buddha doesn't work with GHC 6.4

3. I can't find Freya

4. I can't find HsDebug. Maybe it's part of the fptools cvs
repository? But solander.dcs.gla.ac.uk seems to be down :(

But getting a stack backtrace when there is an error should be a
pretty basic feature. It's very hard to debug a large program when you
can randomly get messages like "*** Exception: Prelude.head: empty
list" and have no idea where they came from. So GHC's many features
become much less useful when there is no debugger which supports a
program that has been written with them.

Furthermore, in my opinion, this sort of error location information is
much more valuable to debugging a program, than being able to step
through its execution, which is the more difficult problem that a lot
of the debuggers seem to be aimed at solving. So maybe it would be
good if GHC had basic stack trace support built in? It could be a
compiler option, which would produce slower but more debuggable
code...

Frederik

-- 
http://ofb.net/~frederik/