[Haskell] Re: A few newbie questions about tracing/debugging andorder of execution

[Srinivas Nedunuri]

I agree with the suggestions of the other posters. Sometimes I'll also use 
"error <data to print>" to get a "one time" breakpoint :-)
cheers

"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?

H

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 ...
>               then
>               else
>            )
>
> 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
>
>