Trace and laziness

[Alexander Dunlap]

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.

I would have submitted a proposal on this, but I'm not sure about the
design decisions that went into using the C version for GHC or about
the best way to go about it. There are a number of workarounds (define
my own function, don't print the whole list), so this probably isn't
very high-priority if there are important other considerations.

Alex