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/