FW: lazy file reading in H98
Wed, 4 Apr 2001 07:36:30 -0700
I'm working on this text right now. Check out
and see if you think it's improved
| -----Original Message-----
| From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk]=20
| Sent: 03 April 2001 17:04
| To: firstname.lastname@example.org
| Subject: Re: FW: lazy file reading in H98
| > (1) At least, the definition should say that the behaviour
| > is undefined if a program ever writes to a file that it
| > has read with `readFile' or `hGetContents' before.
| The Library Report is already stronger than this. The=20
| behaviour is fully defined: an error should be raised. =20
| Here's what it says:
| > Implementations should enforce as far as possible, locally=20
| to the Haskell
| > process, multiple-reader single-writer locking on files. =20
| ... If any
| > open or semi-closed handle is managing a file for input,=20
| new handles=20
| > can only be allocated if they do not manage output.
| > ...
| > Error reporting: the openFile computation may fail with=20
| > isAlreadyInUseError if the file is already open and cannot be=20
| > reopened.
| The only very slightly confusing aspect is that the handles=20
| used by "readFile" and "writeFile" are internal, not written=20
| directly by the programmer. Perhaps the description of this=20
| behaviour should be moved up from the 11.3.1 "Opening Files"=20
| subsection to the enclosing 11.3 section, because it is more=20
| generally applicable.
| Subsection 11.2.1 "Semi-closed Handles" should mention=20
| "readFile" in addition to "hGetContents". It could also=20
| explicitly refer to the multiple-reader single-writer=20
| restriction, which is not otherwise mentioned here.
| Libraries mailing list