[Haskell-cafe] Re: how do you debug programs?

[Claus Reinke]

"scientists, who ought to know,
 assure us that it must be so,
 oh, let us never, never, doubt,
 what nobody is sure about."

 (or something like that..;-)

as everyone else in this thread, I have my own experiences and
firm opinions on the state of debugging support in Haskell (in
particular on the apparent ease with which operational semantics
or stepwise reduction are often dismissed), but just a few points:

- if you're sure about anything, that probably just means you've 
    stopped thinking about that thing - not a good position for
    imposing your assured opinion on others, imho.

- a debugger is (mainly) a tool for finding and removing bugs:

    - if you're crawling through the machine's circuitboards in
        search of a real bug, that might be a screwdriver, a
        flashlight, and a circuitdiagram/floorplan

    - if you don't like to use computers to augment your
        mental processes, that might be pencil and paper

    - if you do like to use computers to augment your
        mental processes, that might be some piece of software

- what kind of software might be helpful in debugging
    depends as much on what you are debugging as on
    your individual approach to debugging

- assuming that you're not debugging the hardware, compiler,
    runtime system, or foreign code, functional languages free 
    you from many sources of bugs. but not of all sources.

- simplifying the code until it becomes easily comprehensible
    is a good habit anyway, and it does help to expose bugs
    that creep in while you're juggling too many balls at once
    (is the code "obviously correct" or "not obviously wrong"?).

    for those so inclined, tools can help here, too: they can
    expand our limits of comprehension, they can assist in
    the simplification, they can highlight big-balls-of-mud in
    your code, etc.

- often, finding bugs is linked to comprehending the program's
    operational behaviour, so that you can be sure that it is
    going to do all that you need it to do, and nothing else.
    that in itself does not imply, however, that you need to 
    include your language's implementation into the set of 
    things to debug.

- it is perfectly possible to study the operational behaviour
    of functional programs without resorting to implementation
    details - that falls under operational semantics, and last 
    time I checked, it had become at least as well respected
    as denotational semantics, not least because of its successes
    in reasoning about programs in concurrent languages. 

- a useful equivalent to observing instruction-by-instruction
    state changes when debugging imperative programs is to
    observe reduction-by-reduction program transformations
    when debugging functional programs. 

    based on operational semantics, tool support for this 
    approach is not just possible, but was used with good 
    success in the past (interested parties might like to browse, 
    eg, the 1994 user's guide for PI-RED, or the 1996 papers 
    on teaching experience, in FPLE, and system overview, in JFP:
    http://www.informatik.uni-kiel.de/~wk/papers_func.html
    ), just not for Haskell. 

    note that this constitutes a semantics-based inspection at 
    the language level, completely independent of the actual 
    implementation below. hiding implementation details while
    presenting a high-level operational semantics is a non-trivial
    exercise that includes such topics as variables, bindings 
    and substitution, as well as retranslating low-level machine
    states to corresponding intermediate high-level programs.

so, while there are reasonable and less reasonable ways of
using debuggers, the question is not whether or not there
should be debuggers, but what kind of tools we have or
need to help debugging and, more generally, comprehending,
Haskell programs. and if the state of the art indicates that
such tools are either kludges (affecting program semantics,
exposing low-level machine details, etc), do not cover the 
whole Haskell-in-use, or simply don't help those who'd
like to use them, then that state is not good. it is a lot better
than it used to be, but far from optimal.

thinking helps, but claiming that tools can't help doesn't.

claus