[Haskell-cafe] getContents and lazy evaluation

[Robert Dockins]

On Friday 01 September 2006 15:19, Tamas K Papp wrote:
> Hi,
>
> I am newbie, reading the Gentle Introduction.  Chapter 7
> (Input/Output) says
>
>   Pragmatically, it may seem that getContents must immediately read an
>   entire file or channel, resulting in poor space and time performance
>   under certain conditions. However, this is not the case. The key
>   point is that getContents returns a "lazy" (i.e. non-strict) list of
>   characters (recall that strings are just lists of characters in
>   Haskell), whose elements are read "by demand" just like any other
>   list. An implementation can be expected to implement this
>   demand-driven behavior by reading one character at a time from the
>   file as they are required by the computation.
>
> So what happens if I do
>
> contents <- getContents handle
> putStr (take 5 contents) -- assume that the implementation
>        	       		 -- only reads a few chars
> -- delete the file in some way
> putStr (take 500 contents) -- but the file is not there now
>
> If an IO function is lazy, doesn't that break sequentiality?  Sorry if
> the question is stupid.

This is not a stupid question at all, and it highlights the main problem with 
lazy IO.  The solution is, in essence "don't do that, because Bad Things will 
happen".  It's pretty unsatisfactory, but there it is.  For this reason, lazy 
IO is widely regarded as somewhat dangerous (or even as an outright 
misfeature, by a few).

If you are going to be doing simple pipe-style IO (ie, read some data 
sequentially, manipulate it, spit out the output),  lazy IO is very 
convenient, and it makes putting together quick scripts very easy.  However, 
if you're doing something more advanced, you'd probably do best to stay away 
from lazy IO.

Welcome to Haskell, BTW  :-)

> Thanks,
>
> Tamas

-- 
Rob Dockins

Talk softly and drive a Sherman tank.
Laugh hard, it's a long way to the bank.
       -- TMBG