I'm working on this text right now. Check out
=09
http://research.microsoft.com/~simonpj/tmp/haskell98-library-html/
and see if you think it's improved
Simon
| -----Original Message-----
| From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk]=20
| Sent: 03 April 2001 17:04
| To: libraries@haskell.org| Subject: Re: FW: lazy file reading in H98
|=20
|=20
| > (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.
|=20
| 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:
|=20
| > 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.
|=20
| 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.
|=20
| 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.
|=20
| Regards,
| Malcolm
|=20
| _______________________________________________
| Libraries mailing list
|Libraries@haskell.org=20
|http://www.haskell.org/mailman/listinfo/libraries|=20