[Haskell] Re: A few newbie questions about tracing/debugging
andorder of execution
nedunuri at cs.utexas.edu
Thu Dec 29 11:51:24 EST 2005
I agree with the suggestions of the other posters. Sometimes I'll also use
"error <data to print>" to get a "one time" breakpoint :-)
"Hunter Kelly" <retnuh at gmail.com> wrote in message
news:75a1c1310512280907w6907badey7d4187592ce7f3fd at mail.gmail.com...
Yes, thank you, that did the trick! It produced the output for all steps,
and in the order I would expect.
Are there other techniques that people use to get debugging output?
On 12/28/05, Robert Dockins <robdockins at fastmail.fm> wrote:
> On Dec 28, 2005, at 6:10 AM, Hunter Kelly wrote:
> > Heya, I decided to play around with Haskell and see what it's like.
> > I used a small problem to explore it. Basically, given two words,
> > find the least number of 1 letter changes that will go from one
> > word to the other (e.g. for "fig" and "dog" either fig -> fog ->
> > dog or
> > fig -> dig -> dog).
> > I came up with a solution, but I have to say it was quite difficult to
> > get any debugging information, and when I did, the result was fairly
> > surprising!
> I see you are using Debug.Trace to generate your debug messages. The
> 'trace' function is a sort of strange one, because it breaks the
> usual rules that Haskell follows; it allows you to generate output in
> the middle of a pure computation. It works by generating output
> _when it is evaluated_. However, without the IO monad to make
> everything sequenced and well-behaved, it can be difficult to predict
> when that will occur. In the particular program you posted, the
> 'trace' thunk is not evaluated until after the recursive call has
> completed, which gives the reversed output. Furthermore, when there
> is no solution, the 'trace' thunk isn't evaluated at all (the magic
> of laziness!), so you never see that output.
> To make your traces show up where you expect, you need to make sure
> that your trace function gets forced earlier and on both success and
> failure paths. Since your function is written as a big let...in
> if ... block you can do something like this:
> ..... =
> let ...
> in trace traceString
> (if ...
> That way, the trace will be output before the 'if' is evaluated, so
> you will get output for both branches. I can't tell from a quick
> inspection if it will return the results in the order you expect, but
> I think it may.
> Rob Dockins
> Speak softly and drive a Sherman tank.
> Laugh hard; it's a long way to the bank.
> -- TMBG
More information about the Haskell