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