[Haskell-cafe] Haskell Propeganda
Niels Aan de Brugh
nielsadb at gmail.com
Mon Sep 1 16:04:49 EDT 2008
On Sun, Aug 24, 2008 at 5:44 AM, Thomas M. DuBuisson <
thomas.dubuisson at gmail.com> wrote:
> 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.
> > 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
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe