Trace and laziness

[Alexander Dunlap]

Oops, forgot to CC the list


---------- Forwarded message ----------
From: Alexander Dunlap <alexander.dunlap at gmail.com>
Date: Sun, Jul 13, 2008 at 11:52 AM
Subject: Re: Trace and laziness
To: Isaac Dupree <isaacdupree at charter.net>


On Sun, Jul 13, 2008 at 3:24 AM, Isaac Dupree <isaacdupree at charter.net> wrote:
> Alexander Dunlap wrote:
>>
>> Hi all,
>>
>> I've come to rely on Debug.Trace.trace as a tool to figure out what my
>> programs are doing, so I was somewhat surprised to realize that it
>> doesn't handle very long lists well.
>>
>> For example, if I do "trace (show [1..1e9]) 0", the program doesn't
>> produce any output until the entire list is evaluated (and if the list
>> is infinite, it just doesn't do anything). If I replace this with
>> "unsafePerformIO $ hPutStrLn stderr (show [1..1e9]) >> return 0", the
>> numbers from 1 to 1e9 start appearing on the screen immediately.
>>
>> Looking at the source of Debug.Trace, it looks like the lazy version
>> (using hPutStrLn stderr) is implemented, but ifdef'd out for GHC,
>> which uses a (presumably strict) C version. It would be nice if there
>> was a way for GHC to do the lazy tracing as well.
>
> you seem to be right, although I hope that buffering effects don't change it
> (ghc 6.8.2) :
> $ ghci -e "Debug.Trace.trace ('a':'b':(Debug.Trace.trace ['C'] 'c'):'d':[])
> ()"
> C
> abcd
> ()
>
> I find this behavior important, because when it was the lazy version, one
> thing's trace-'show' would always be interrupted in the middle of the line
> by something else's trace-show, etc., so it was nearly impossible to
> decipher.  Strictness isn't the nicest solution but it works most of the
> time... clearly not all the time...
>
> -Isaac
>

Perhaps we need a trace and a trace' (lazy version and strict version) then?

Alex