Well, I actually meant more something like the imperative equivalences
of "code coverage tools" and "unit testing tools", because I've read
rumors that in Haskell, unit testing is more difficult because lazy
evaluation will cause the "units" that got tested to be evaluated
completely different depending on how they are used. In strict
languages, this is not the case.
Neil Mitchell wrote:
Hi Peter,
The way I see it as a newcomer, Haskell shifts the typical imperical
programming bugs like null pointers and buffer overruns towards
"space/time leaks", causing programs that either take exponentially long
to complete, stack overflow, or fill up the swap file on disc because
they consume gigabytes of memory.
Time bugs are quite rare - usually a simple profiling will fix them
up, and they are exactly the same sorts of bugs that exist in an
imperative programming language. Usually its a case of picking a
better algorithm, or thinking clever thoughts.
Space leaks are much more tricky - there are profiling tools, but I've
never got enough experience using them to say anything more than that.
Other bugs I found are incomplete
pattern matches at runtime, but I already got an email of how to fix
this using an external tool
Did the email suggest using Catch? http://www-users.cs.york.ac.uk/~ndm/catch/
If you care enough about pattern matching, you can eliminate them all
statically.
Thanks
Neil
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
