I'm working on this text right now. Check out 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] | Sent: 03 April 2001 17:04 | To: libraries@haskell.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 | behaviour is fully defined: an error should be raised. | Here's what it says: | | > Implementations should enforce as far as possible, locally | to the Haskell | > process, multiple-reader single-writer locking on files. | ... If any | > open or semi-closed handle is managing a file for input, | new handles | > can only be allocated if they do not manage output. | > ... | > Error reporting: the openFile computation may fail with | > isAlreadyInUseError if the file is already open and cannot be | > reopened. | | The only very slightly confusing aspect is that the handles | used by "readFile" and "writeFile" are internal, not written | directly by the programmer. Perhaps the description of this | behaviour should be moved up from the 11.3.1 "Opening Files" | subsection to the enclosing 11.3 section, because it is more | generally applicable. | | Subsection 11.2.1 "Semi-closed Handles" should mention | "readFile" in addition to "hGetContents". It could also | explicitly refer to the multiple-reader single-writer | restriction, which is not otherwise mentioned here. | | Regards, | Malcolm | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries |