On Thu, 2005-09-01 at 14:48 -0700, Frederik Eaton wrote:
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.
Adding an extra argument to record the application context is one part of the transformation employed by buddha.
Are the following correct?
1. Hat requires users to restrict themselves to a certain small subset of the standard libraries, and to use hmake
Depends what you mean by standard libraries. As far as I know it supports all the libraries which are specified in the Haskell 98 Report. I believe it also supports some libraries in the new hierarchy that come with the compilers. Also, many libraries can be used by Hat, if you include them in your own source tree. Supporting all libraries that come packed with GHC would be nice, but there are numerous hurdles that need to be jumped over to get to that point. For instance, some libraries do not use portable Haskell code. Also the issue of how libraries are distributed in Haskell is a little bit in flux at the moment, since Cabal is still being polished.
2. Buddha doesn't work with GHC 6.4
True. This is a cabal issue, that I haven't had time to resolve. buddha is limited to even fewer libraries than Hat. So if your program doesn't work with Hat it will probably not work with buddha. I realise this is a big problem. I'll be the first to admit that buddha is still an experimental system. It works fine for some small programs, and might be useful to beginner programmers. I'm trying to finish my thesis at the moment, so development has stopped, but I have plenty of ideas to try out later on.
3. I can't find Freya
You can get a binary for Sparc off Henrik Nilsson's homepage: http://www.cs.nott.ac.uk/~nhn/ Note that Freya supports a subset of Haskell. From memory, no IO functions, and no classes. Probably none of the extensions of GHC.
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 :(
I don't know about the status of HsDebug. I believe it is not being maintained. It relies on optimistic evaluation, which is in an experimental branch of GHC.
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.
I agree with you. Note that debugging lazy functional languages is a notoriously difficult problem. Work is being done, but the Haskell community is small, and there is a definite shortage of labour. Cheers, Bernie.