Trace and laziness

[Isaac Dupree]

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