IO monad and lazy evaluation

[Derek Elkins]

On Fri, 23 May 2003 14:03:47 +0200 (CEST)
Elke Kasimir <elke@espresto.com> wrote:

> 
> On 22-May-2003 Glynn Clements wrote:
> > The problem isn't monads, or lazy functions, or even the
> > interactions between them. The problem is specifically lazy I/O,
> > which is basically a fudge which usually works in simple cases.
> > 
> > The "normal" (i.e. strict) I/O functions are perfectly safe.
> 
> 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, and given
> that such a copy almost always does not come at such a high cost.

This is -a- problem with lazy IO but not -the- problem.  This problem
applies (or not) to strict IO, albeit at least with strict IO you'll
definitely have what you have. The problem is that-within the language-
you can apply strict IO functions (in this case, hClose) to a file that
is being read lazily.  This is also the reason why Ketil Z. Malde said
that readFile -is- safe, as without access to the handle you are
limited to what you can do to a file.

> Unfortunately, the number of file handles is sometimes limited so
> that one is sometimes forced to close lazily read files explizitly
> which is rather tedious...

Combining explicit file closing to a lazily read file is
dangerous, that is the point of this whole thread.  Either use strict
IO throughout or solve this problem with strictness annotations
(deepSeq/rnf may help here). (There is one example where I solved this
problem with a single well-placed $!)  If you do explicitly close a
lazily read file then you better mean what you are saying.