readFile is very convenient, up to a point.
Suppose I want to read a file and write filtered contents back to it
(don't mind a backup). Now I can:
- Rely on Unix behavior of allowing removing open files which still
exist until closed. I think Haskell does not enforce that and
on other platforms it will not work.
- Don't use readFile, but repeat hGetChar and catch isEOFError to read
file non-lazily.
- Use hGetContents and try something like `seq (length contents)'
to force reading all the contents before hClose.
None of the above solutions is nice and they lose some properties.
Did I miss something?
If hClosing a semi-closed handle caused reading the whole pending
input into memory (when the read contents are still possibly needed),
one could often forget about lazy semantics of hGetContents and use
hGetContents here. But it could not be a good idea, sometimes we may
not need it. Maybe there should be two variants of hClose? It would
be better than non-lazy hGetContents variant because it would allow
lazy reading part of the file and deciding later how to proceed.
BTW, is calling hClose required to properly flush the buffers etc.?
Is it officially required for reading files?
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
