Brandon S. Allbery KF8NH wrote:

On 2009 Feb 20, at 4:38, Serge D. Mechveliani wrote:

...

The first command outputs

--------------------------------- t = ((a : nil) + (b : nil)) Bug: substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X: sort mismatch in substitution ---------------------------------

And the second command skips (in ./log) the line of t = ... Who can tell what is the matter?

The ghc runtime doesn't flush stdout when an exception stops the program. This is arguably a bug in the runtime; if you set stdout to line buffering or no buffering you should get pretty much the same output from both. (It's still possible for buffering to cause lines to come out in a different order, so you might prefer unbuffered).

stdout should be flushed when the program exits, regardless of whether it exits as a result of a clean exit or an exception. I've just checked the code, and that's certainly what is supposed to happen. If anyone has evidence to the contrary, please submit a bug report! Cheers, Simon

Malcolm Wallace wrote:

Simon Marlow wrote:

...

stdout should be flushed when the program exits, regardless of whether it exits as a result of a clean exit or an exception. I've just checked the code, and that's certainly what is supposed to happen. If anyone has evidence to the contrary, please submit a bug report!

I believe flushing of file handles on program exit is handled by finalizers attached to the handle. Until recently, ghc did not guarantee that any finalizer would ever run.

Not exactly. There's a top-level exception handler that flushes stdout and stderr, so they always get flushed on exit (or at least, they are supposed to). Look in base:GHC.TopHandler for the code. Other handlers will only get flushed if their finalizers run, and nothing has changed here: we now guarantee execution of C finalizers, but that doesn't apply to the finalizers for Handles, which are Haskell code. Cheers, Simon