>> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
