Why aren't files flushed at exit?

If you open a file for writing and then exit with output unflushed, then Haskell does not flush the file for you. In ghci the program seems to work, but then when you compile it in ghc it mysteriously fails. I've just been bitten by this, but when I went to the bug tracker I found http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes this behaviour and was resolved as "invalid". So presumably this behaviour is by design. Given that most environments get this right, why doesn't Haskell? Paul.

On Sun, Jul 17, 2011 at 10:41 AM, Paul Johnson
If you open a file for writing and then exit with output unflushed, then Haskell does not flush the file for you. In ghci the program seems to work, but then when you compile it in ghc it mysteriously fails.
I've just been bitten by this, but when I went to the bug tracker I found http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes this behaviour and was resolved as "invalid". So presumably this behaviour is by design.
Given that most environments get this right, why doesn't Haskell?
If you are asking why finalizers are not guaranteed to run, I don't really know the answer for sure. But if you are asking why that bug was marked invalid, then that's because it's good practice anyway to know the lifetime of you handles, specially since they are a scarce resource. If you need a handle for the whole lifetime of your program, use withFile on the main function. If you don't need it for the whole lifetime, then you already should be careful about not leaving it opened. If your program is a long-running process, maybe you should also hFlush at some points to minimize damage on hardware failures and system reboots. Cheers, =) -- Felipe.

Quoth Felipe Almeida Lessa
On Sun, Jul 17, 2011 at 10:41 AM, Paul Johnson
wrote: If you open a file for writing and then exit with output unflushed, then Haskell does not flush the file for you. In ghci the program seems to work, but then when you compile it in ghc it mysteriously fails.
I've just been bitten by this, but when I went to the bug tracker I found http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes this behaviour and was resolved as "invalid". So presumably this behaviour is by design.
Given that most environments get this right, why doesn't Haskell?
If you are asking why finalizers are not guaranteed to run, I don't really know the answer for sure.
But if you are asking why that bug was marked invalid, then that's because it's good practice anyway to know the lifetime of you handles, specially since they are a scarce resource. If you need a handle for the whole lifetime of your program, use withFile on the main function. If you don't need it for the whole lifetime, then you already should be careful about not leaving it opened. If your program is a long-running process, maybe you should also hFlush at some points to minimize damage on hardware failures and system reboots.
The use of withFile on the main function is a good practice in Haskell only because of this defect in the GHC library implementation. There's no question, if there were two competing Haskell library implementations, GHC and one that worked like buffered I/O in other languages, which one would better support Haskell programmers. It's too bad that doesn't qualify it as "valid" bug. Donn

On Sun, Jul 17, 2011 at 1:40 PM, Donn Cave
The use of withFile on the main function is a good practice in Haskell only because of this defect in the GHC library implementation.
Well, I've always closed my handles on all languages I've programmed. Actually, now I remember that some students were bitten by the same bug in Pascal.
There's no question, if there were two competing Haskell library implementations, GHC and one that worked like buffered I/O in other languages, which one would better support Haskell programmers. It's too bad that doesn't qualify it as "valid" bug.
Having this feature may be nice if you ever forget to close your handles. But if this is a good practice or not is an orthogonal issue. (Actually it is a non-issue because only one of the practices work today =P). Cheers, -- Felipe.

Is there really no question? I question the assertion, for one. Just because a language allows a bad habit doesn't mean it's a feature. Leaving your handles open can lead to unpredictable results, which is somewhat anathema to the idea of correct programs, unless broken features are part of your spec. Out of curiosity, which languages `get this right', to your way of thinking? On Jul 17, 2011, at 12:40 PM, Donn Cave wrote:
There's no question, if there were two competing Haskell library implementations, GHC and one that worked like buffered I/O in other languages, which one would better support Haskell programmers. It's too bad that doesn't qualify it as "valid" bug.
Donn
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Jack Henahan jhenahan@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ==

On Sun, Jul 17, 2011 at 18:03, Jack Henahan
Is there really no question? I question the assertion, for one. Just because a language allows a bad habit doesn't mean it's a feature. Leaving your handles open can lead to unpredictable results, which is somewhat anathema to the idea of correct programs, unless broken features are part of your spec.
Out of curiosity, which languages `get this right', to your way of thinking?
It's not languages; it's system libraries. And system libraries — *not* the programs that use them — that don't clean up after themselves are broken. That kind of thing used to lead to lots of resource leakage in older Windows, for example. This is not to say that programs that rely on it are correct; it *is* to say that, by the exact same reasoning, it is incorrect for runtime libraries to assume that the *programs that use them* are correct. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
participants (5)
-
Brandon Allbery
-
Donn Cave
-
Felipe Almeida Lessa
-
Jack Henahan
-
Paul Johnson