error function is not lazy

[NeilMitchell]

C:\Neil\Temp>type Test.hs
main = error $ cycle "Hello\n"
C:\Neil\Temp>ghc --make Test.hs
[1 of 1] Compiling Main             ( Test.hs, Test.o )
Linking Test.exe ...
C:\Neil\Temp>test
-- hangs forever

The error message seems to get buffered, which means long/infinite messages are never displayed. GHCi does evaluate error lazily. The error function is particularly useful for debugging, which is where I encountered this problem.

It appears trace has a similar issue of buffering in GHC compiled programs, but I am not certain.

[ajd]

Trace does indeed have a similar issue, I reported this at  http://www.haskell.org/pipermail/libraries/2008-July/010199.html.

[simonmar]

Trace is supposed to work like this, the idea is that trace messages don't get interleaved with each other.

For error, the exception is passed to the RTS for printing, because in a Windows non-console program the error will pop up in a message box. Passing the message to the RTS of course involves serialising it. I suppose we could detect whether the program was running on the console and use lazy output, but the program will still hang in a non-console environment.

Incedentally, test cg016 tests something very similar (nested errors).

[Isaac Dupree]

well, at least it could be split up into two pieces: the fact that there is an error, and the contents of the error, if possible. Usually it's rather useful to know it's not just an infinite loop. Perhaps there is some way to make two RTS calls, and have the first one put up an "Error" dialog and the second one (if it ever happens) add the error's contents? (e.g. fix error and error (fix ('a':)) both cannot have their error strings serialized.) It might be useful to have a third division, say, the first 500 characters of the error message, or however many characters have been successfully generated within, say, 3 seconds of CPU time. Hmm, seems a bit complicated :-/ but going to an effort to print whatever you have of the error message will be useful for tracking where it came from (where the bug is -- which error call it is).

[igloo]

You can use a top-level error handler if you want to do something like this, so I think the current behaviour is a reasonable default.