<div dir="ltr"><div class="gmail_quote">On Sun, Aug 24, 2008 at 5:44 AM, Thomas M. DuBuisson <span dir="ltr">&lt;<a href="mailto:thomas.dubuisson@gmail.com" target="_blank">thomas.dubuisson@gmail.com</a>&gt;</span> wrote:<br>
<div dir="ltr"><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>wrt head [], Niels said:<br>
&gt; So now what? Action plan = []<br>
<br>
</div>Oh come now. &nbsp;Between ghci, hpc, and manual analysis I&#39;ve never hit a<br>
Haskell error and thrown my hands up, &quot;I can&#39;t go any further, I&#39;m at a<br>
complete loss!&quot; &nbsp;Also it helps that I run into this extremely rarely - I<br>
have a larger habit of hidding black holes :-(</blockquote></div><div><br>I&#39;ve never used Haskell in an engineering environment, but I have encountered problems that would&#39;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&#39;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.<br>

<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Niels said:<br>
&gt; Thank you for the URL, but I&#39;m aware of the work in GHC(i).<br>
<br>
</div>It might interest you to know some people actually use hpc for debugging<br>
with reasonble success - it colors the unevaluated sections and this can<br>
be very helpful in determining where a program stopped and threw an<br>
exception.</blockquote></div><div><br>I haven&#39;t used HPC myself&nbsp; (I use -fwarn-incomplete-patterns but that&#39;s about it for &quot;coverage&quot; 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&#39;s solution. Just like the trace function (tracing/logging itself is useful, but not as a debugger tool).<br>

</div><div class="Ih2E3d"><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you have your eyes on the future you should see Dana Xu&#39;s work on<br>
static contract checking (check out her Cambridge page).</blockquote></div><div><br>Thanks for the suggestion, I&#39;ll be sure to check that out.<br><br>I use design by contract on a daily basis, but in a language like C++ it&#39;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&#39;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).<br>

<br>Regards,<br>Niels<br><br></div></div></div>
</div><br></div>