IO monad and lazy evaluation

[Glynn Clements]

Elke Kasimir wrote:

> >> Since Haskell is lazy by default, I consider lazy file reading to be
> >> the more natural choice, and also a safe one on operating systems
> >> like unix who lock a copy of the file at the time it's opened,
> > 
> > I'm not quite sure what you're saying here, but I think that you're
> > wrong. It appears that you are confusing Unix (which doesn't lock
> > files automatically) with Windows (which automatically locks a file
> > unless the program indicates that it allows concurrent access).
> 
> You're right - My use of the term "locked" is inappropriate and
> obviously confusing. What I was trying to indicates is that if some
> file "Foo" is opened using >> readFile "Foo" << the effect is that
> you get an object that can't be changed from the outside,

While readFile doesn't "leak" a handle to the rest of the program,
nothing prevents the program from doing:

	openFile "Foo" WriteMode

and nothing prevents other processes from writing to that file. In
either of those situations, the exact data which readFile returns
depends upon when readFile actually performs the reads.

> so that it
> is not so important to ensure that the read operation on that file
> is finished at some specific point in time, and even may be never
> known to have been finished for sure. If it was possible to open
> arbitrary many files that way - and opening "the same file"
> arbitrary many times for reading, "not so important" could be
> changed into "not important" in the previous statement.

Exhausting file handles isn't the only problem which occurs if the
consumer doesn't close the file. E.g.:

	createTheFile "Foo"
	string <- readFile "Foo"
	consumeString string
	removeFile "Foo"

IIRC, Windows refuses to delete open files, so removeFile will fail if
the file is still open (i.e. if consumeString doesn't read its entire
input).

-- 
Glynn Clements <glynn.clements@virgin.net>