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

[Claus Reinke]

 >> thinking helps, but claiming that tools can't help doesn't.
> 
> Lets be absolutely clear about this: I've never claimed that
> tools can't help. In this thread I've been using the term
> debugger in the narrow sense implied by the OP's question --
> something that steps through the execution of the code. Such
> a debugger is inappropriate for Haskell programmers, and
> doubly so for beginners.

well, then it is clear that we disagree on this. imho, being 
able to step through reductions is very appropriate for all
functional programmers (**), and an essential exercise 
for beginners. 

and if that is true for tiny examples on paper, then there 
should be tool support for applying it to larger programs.

from experience with the PI-RED systems, there are few
cases where one can apply such a tool without thinking
(eg. let it run till it gets stuck on an error, go a few steps
back to see where that erroneous part was constructed;
or let it run for a large number of steps, then check why
and where the program it is still growing instead of 
terminating). (*) 

after the initial learning phase, where such a stepper helps
to form the student's mental model of program evaluation,
the majority of debugging cases need to combine thinking
with experimentation, but dropping either of these two
ingredients makes the problem much harder. 

and it is nice to be able to do the experiments without 
having to switch tools or mindsets (although there are 
many ways in which the old PI-RED systems could have 
been improved, not to mention lessons learned from 
other tools, like Hat, that were developed for Haskell 
because there were no reduction systems for it).

claus

(*) note that the programmer never saw thunks, or 
    stacks, let alone heap objects or abstract machine
    code, only high-level program text, transformed by 
    reductions. intermediate programs were fully editable,
    in no way distinguished from the original programs 
    entered by the programmer, so one could make some 
    local observations, changes and reductions, then 
    continue with the overall reduction, or return to the 
    original program. compilation, decompilation, and 
    presentation were implicit, under the hood.

    for the PI-RED developers, though, there were 
    *separate* debugging tools that would allow them 
    to inspect the abstract machine's stack, heap, etc.. 
    and only if those failed to indicate the problem, 
    would they have to resort to C-level debugging 
    tools, another level lower.

(**) in fact, Berkling used to argue that was true for 
    all declarative programmers, and he extended his 
    ideas and machines to functional logic languages