Trace and laziness
isaacdupree at charter.net
Sun Jul 13 06:24:00 EDT 2008
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']
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...
More information about the Libraries