Oops, forgot to CC the list
---------- Forwarded message ----------
From: Alexander Dunlap
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