[Haskell-beginners] Confused about lazy IO

[Kim-Ee Yeoh]

On Fri, Mar 15, 2013 at 5:52 AM, Jacek Dudek <jzdudek at gmail.com> wrote:
> (1) What is the proper way to reason about lazy IO?

Lazy IO is pull-driven. The stuff that comes out of a lazy read needs
to be /pulled/ by some weight to be actually read. The function
putStrLn exerts weight, as you've discovered. So does writeFile.

What's weightless is a pure function "lifted" (by liftM aka fmap) into IO.

> (2) Is there some action less arbitrary that what I cooked up in the
> second version that explicitly instructs to release a file or some
> other resource?

Explicitly managing resources means going the whole nine yards of
imperative programming. Which means reading and writing in
program-specified chunks, opening and closing file handles, dealing
with IO errors, etc.

If this sounds a lot like manual memory management, that's because it is.

So the dream is: is there an analogue of GC doing for IO what GC now
does for RAM?

Lazy I/O can be thought of as an hors d'oeuvre of that dream. Some
have complained about a queasy feeling in the stomach afterward.

Some of the strongest detractors of lazy I/O have proposed iteratees
as a more realistic substitute.

Just a few hours ago, Dan Doel wrote an email [1] to the haskell-cafe
list explaining how some problems of Lazy I/O can be resolved by even
more laziness, not less. I read his email as keeping the dream alive.
(Others may differ.)

GC gives the illusion of infinite RAM.

What would the illusion of infinite IO be like?

So to recap: if you run into issues with Lazy I/O, the fixes include:

* Replace lazy with strict I/O. Make sure you have enough RAM,
especially if you still use String, as opposed to ByteString.

* Use strict I/O but leave off readFile. Chunk explicitly. Code imperatively.

* Use iteratees

* Use unsafeInterleaveIO. Watch the envelope bend.

[1] http://www.haskell.org/pipermail/haskell-cafe/2013-March/107027.html

-- Kim-Ee