Sigbjorn Finne <[EMAIL PROTECTED]> wrote,
> The behaviour is well defined, Haskell98 enforces a
> single-writer, multiple reader locking on files (Sec.
> 11.3.1 of the library report) which also extends
> to semi-closed handles/files.
Good point - I missed that one. In other words, the report
already enforces Solution (1) and both GHC and Hugs do not
conform to the report.
One may argue that the report is not entirely precise, as
11.3.1 talks only about handles, whereas we had problems
with `readFile' and `writeFile', which do not make the use
of handles explicit. So, a clarification may be in order
here (as I searched the report for occurrences of `readFile'
explicit mentioning of this would actually have helped in my
case).
Cheers,
Manuel
> > -----Original Message-----
> > From: Simon Peyton-Jones
> > Sent: Tuesday, September 05, 2000 01:10
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Cc: Simon Peyton-Jones
> > Subject: RE: lazy file reading in H98
> >
> >
> > Folks,
> >
> > Finalising the Haskell 98 report is (still) on my to-do list.
> > I plan to
> > do it after ICFP, but I need a clear week which is why I've been
> > procrastinating.
> > And comments do keep coming in occasionally. Manuel's is a
> > case in point.
> >
> >
> > I'd be interested to hear people's opinion about the lazy-file read
> > question.
> > I'm not prepared to add new functions to Haskell 98, but I think
> > the clarification of (1) or (2) below would be useful. (2) is nice
> > but it makes *all* file reading more expensive, perhaps significantly
> > so (e.g. making a complete copy of the file). So I am
> > personally inclined
> > to go for (1) and require Haskell programmers to do the
> > consequent file-name
> > changing themselves.
> >
> > I'm sending this message to the haskell-cafe!
> >
> > Simon
> >
> > | -----Original Message-----
> > | From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]]
> > | Sent: 05 September 2000 02:10
> > | To: [EMAIL PROTECTED]
> > | Subject: lazy file reading in H98
> > |
> > |
> > | In an assignment, in my class, we came across a lack of
> > | specification of the behaviour of `Prelude.readFile' and
> > | `IO.hGetContents' and IMHO also a lack of functionality. As
> > | both operations read a file lazily, subsequent writes to the
> > | same file are potentially disastrous. In this assignment,
> > | the file was used to make a Haskell data structure
> > | persistent over multiple runs of the program - ie,
> > |
> > | readFile fname >>= return . read
> > |
> > | at the start of the program and
> > |
> > | writeFile fname . show
> > |
> > | at the end of the program. For certain inputs, where the
> > | data structure stored in the file was only partially used,
> > | the file was overwritten before it was fully read.
> > |
> > | H98 doesn't really specify what happens in this situation.
> > | I think, there are two ways to solve that:
> > |
> > | (1) At least, the definition should say that the behaviour
> > | is undefined if a program every writes to a file that it
> > | has read with `readFile' or `hGetContents' before.
> > |
> > | (2) Alternatively, it could demand more sophistication from
> > | the implementation and require that upon opening of a
> > | file for writing that is currently semi-closed, the
> > | implementation has to make sure that the contents of the
> > | semi-closed file is not corrupted before it is fully
> > | read.[1]
> > |
> > | In the case that solution (1) is chosen, I think, we should
> > | also have something like `strictReadFile' (and
> > | `hStrictGetContents') which reads the whole file before
> > | proceeding to the next IO action. Otherwise, in situations
> > | like in the mentioned assignment, you have to resort to
> > | reading the file character by character, which seems very
> > | awkward.
> > |
> > | So, overall, I think solution (2) is more elegant.
> > |
> > | Cheers,
> > | Manuel
> > |
> > | [1] On Unix-like (POSIX?) systems, unlinking the file and
> > | then opening the writable file would be sufficient. On
> > | certain legacy OSes, the implementation would have to
> > | read the rest of the file into memory before creating
> > | a new file under the same name.
> > |
> >
