Fergus Henderson <fjh007@galois.com> writes:

Seeing as Haskell is apparently such a popular language these days, I don't suppose a working debugger would be too much to ask for, would it?

Hah. You're not supposed to debug, just stare at the code until you become enlightened (why did you think it was called Buddha, anyway)? :-)

I've also tried using ghc's profiling to get stack traces, but that doesn't work very well either.

So you know about +RTS -xc.

Thirdly, profiling seems to be incompatible with the use of ghci; there doesn't seem to be any easy way to build a workspace so that you can get stack traces and use ghci in that workspace at the same time.

You can compile with: -prof -auto-all -hisuf p.hi -osuf p.o This will create separate object and interface files for profiling. I haven't really tried juggling GHCi in between, but I think it would ignore those. (Or did you want GHCi to use the profiling info to get the stack traces?)

And ghc is slow enough (even on a 3.2GHz Pentium 4) that recompiling the whole workspace is highly unpalettable.

Compile without -O? Avoid large source files, in particular with large embedded data structures? But yes, it's slow. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

I wrote such a debugger as part of my PhD work. It is called "hsdebug" and you can read the Haskell Workshop paper on it here: http://www.cambridge.intel-research.net/~rennals/hw2003.pdf Unfortunately, HsDebug depends on Optimistic Evaluation, and it seems unlikely that Optimistic Evaluation will appear in a release version of GHC (too hard to maintain, and I've gone off to work for Intel Research). HsDebug is a GDB-style debugger which takes advantage of the fact that Optimistic Evaluation makes programs evaluate in a largely-strict evaluation order. It also uses a trick called "transient tail frames" to allow tail calls to be visible in stack traces. HsDebug can debug any GHC-compilable Haskell program, including GHC itself. -Rob

\begin{gripe}

Seeing as Haskell is apparently such a popular language these days, I don't suppose a working debugger would be too much to ask for, would it? Or even just a decent call stack trace when a program terminates with an exception?

In case you're wondering, yes I have already tried using Hat and Buddha. But I'm trying to debug a real application, not a toy one, and neither Hat nor Buddha support enough of Haskell. Buddha doesn't even come close, as far as I can tell, and Hat lacks support for library modules such as Data.Word.

I've also tried using ghc's profiling to get stack traces, but that doesn't work very well either. Firstly, the stack traces that you get only include function names, not line numbers. Secondly, the stack traces are often incomplete, for reasons that I don't fully understand. One likely cause is tail call optimization. (Is there any option to switch off tail call optimization? I didn't see any such option in the ghc man page.) Thirdly, profiling seems to be incompatible with the use of ghci; there doesn't seem to be any easy way to build a workspace so that you can get stack traces and use ghci in that workspace at the same time. And ghc is slow enough (even on a 3.2GHz Pentium 4) that recompiling the whole workspace is highly unpalettable.

There's a hell of a lot of languages out there that _do_ support decent stack traces when an exception is thrown.

What's the point of using a high-level functional language if it means you're stuck with poor library support and/or stone-age tools?

\end{gripe}

-- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell