> Suppose I want to read a file and write filtered contents back to it
> (don't mind a backup). [...explains why hGetContents doesn't work...]
An entirely reasonable question. The semantics of lazy file
reading in the Haskell98 Library Report is quite hard to understand,
and seems to be oriented more towards easy implementation than
easy use. In particular, it would be very nice if:
the semantics of hGetFileContents was just as if
the entire contents of the file was read instantaneously
[In the case of stdin, and other input ports, that isn't possible,
but it doesn't matter because you can't open such things for writing.]
But that *isn't* the current semantics. The easiest thing to do
is to write a new file and rename at the end, I think.
I'm sure there was extensive discussion of this point when
the I/O library was developed. I don't know if there are any
serious implementation difficulties with the semantics I suggest
above. Maybe Kevin Hammond can remember? [Kevin, I think that
at one stage you had an I/O rationale document; would it be possible
to put it up at haskell.org.]
It would be a Good Thing if someone wanted to have a good look
at the I/O library, propose a coherent set of improvements,
and (preferably) demonstrate they are feasible by implementing them.
Consider it a wish.
Simon
> -----Original Message-----
> From: [EMAIL PROTECTED]
> Sent: Wednesday, September 08, 1999 12:06 AM
> To: [EMAIL PROTECTED]
> Subject: Lazily read streams
>
>
> 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-
