On Fri, 12 Jul 1996, Simon L Peyton Jones wrote:
>
> | a feeling of frustration around here. So here is my question:
> |
> | How do people out there debug Haskell programs???
> |
> | Please note that I am not talking about toy programs of a few dozen
> | lines. How do e.g. the people at Glasgow find the bugs in GHC (which is
> | a fairly large Haskell program)?
>
> You're right that there is a problem. I think that it has been addressed
> only slowly because
>
> a) it's a genuinely difficult problem -- it isn't clear what a debugger
> for a lazy language should do.
I agree in part. However, it's clear to me what in principle a
debugger should do: help to locate the source of inconsistency between
the intended behaviour and the actual behaviour. I don't see that a
lazy language comes into this at all. Perhaps it is more accurate to
say that it isn't clear how a debugger can be built to help in this
respect given the difficulties a lazy language brings to the party.
>
> b) it's a less pressing problem than in many languages -- a common experience
> is that once the program gets past the type checker it works.
I guess many people having written any sizeable programs would contend
this. Fortunately you go on to say
> (b) is clearly a cop-out -- but it helps explain why (in combination with
> (a)) building a debugger hasn't made it to the top of our priority list.
>
> So far as (a) is concerned, there is old work by O'Donnel and Hall,
> more recent work by Henrik Nilsson and Peter Fritzson
> (abstract on http://www.dcs.glasgow.ac.uk/jfp/bibliography/bibliography.html)
> and more recent still by Jan Sparud at York.
>
The problem with this work is that without significant support for
examining data (which as yet I have not seen in any similar debuggers
except mine for Goedel) debugging is still hard due to the size of
data manipulated in "real" programs.
There is also some work by Lee Naish et al. Check
http://www.cs.mu.oz.au/~lee.
>
> There are two sorts of error which are particularly painful:
>
> 1. non-termination. The trouble here is that you get no information
> whatsoever! Stack backtraces are usually unhelpful.
In recursive programming this is a general problem not limited to lazy
programming languages. The initial poster said that developers had
migrated from Prolog. The problem is the same there (although in some
ways compounded by lack of strong typing etc.)
>
> 2. Error "head []". If you take head of nil, or some other similar
> missing-pattern error, then it's often really hard to know who
> the "caller" was. The trouble is that you want to know who
> *built* the thunk (head []) rather than who *demanded* it.
Hazan and Morgan (LNCS749, "The Location of Errors in Functional
Programs", AADEBUG'93) did some work which helps here. The program is
first preporcessed to include extra information about the path taken
to reach each call so that when "head []" is called the error function
can print the call path to that function. This at least can help to
reduce the amount of program that needs to be examined to determine
the problem.
>
>
> My guess is that better info about these two sorts of errors would
> get 50% of the way for 10% of the effort.
>
> Simon
>
>
>
Good luck.
-----------
Dominic Binks [EMAIL PROTECTED]
Aethos Communication Systems Ltd. | 220 Park Avenue | Bristol | BS8 1SB
Telephone: +44 1454 614455 Fax: +44 1454 620527
-----------
"Meditation, 2. _spec_ (in religious use): That kind of private devotional
exercise which consists in the continuous application of the mind to the
contemplation of some truth, mystery or object of reverence, in order that
the soul may increase in love of God and holiness of life." OED
