wrt head [], Niels said:
> So now what? Action plan = []
Oh come now. Between ghci, hpc, and manual analysis I've never hit a
Haskell error and thrown my hands up, "I can't go any further, I'm at a
complete loss!" Also it helps that I run into this extremely rarely - I
have a larger habit of hidding black holes :-(
I've never used Haskell in an engineering environment, but I have encountered problems that would've been easier to analyze with a step function (almost without exception in a stateful computation, e.g. functions using recursion or some state monad). For example, a graphical frond-end to the GHCi debugger would've been really helpful, especially for new users. C/C++ programmers on Linux have gdb but I know nobody that uses the tool directly on the bare command line.
Niels said:
> Thank you for the URL, but I'm aware of the work in GHC(i).
It might interest you to know some people actually use hpc for debugging
with reasonble success - it colors the unevaluated sections and this can
be very helpful in determining where a program stopped and threw an
exception.
I haven't used HPC myself (I use -fwarn-incomplete-patterns but that's about it for "coverage" analysis) but it looks like a powerful tool. Statement and branch coverage are very imporant metrics e.g. to measure test coverage. However, I feel that using a profiler to do a debuggers job is really a poor man's solution. Just like the trace function (tracing/logging itself is useful, but not as a debugger tool).
If you have your eyes on the future you should see Dana Xu's work on
static contract checking (check out her Cambridge page).
Thanks for the suggestion, I'll be sure to check that out.
I use design by contract on a daily basis, but in a language like C++ it's never more than a couple of glorified asserts. My opinion is that if you want to do contracts good (i.e. not with some macro kludge) it needs to be embedded into the language. I've been looking at Spec#, that looks like a very powerful extension to C#. I think contracts could fit even better in a pure functional language. Checking contracts statically would be awesome, but doing dynamic DbC well is already harder than it seems (e.g. in concurrent code that uses locks).
Regards,
Niels