Lazy streams and unsafeInterleaveIO

[Glynn Clements]

Jyrinx wrote:

> So is this lazy-stream-via-unsafeInterleaveIO not so nasty, then, so 
> long as a few precautions (not reading too far into the stream, 
> accounting for buffering, etc.) are taken? I like the idiom Hudak uses 
> (passing a stream of I/O results to the purely functional part of the 
> program), so if it's kosher enough I'd like to get hacking elsewhere ...

It depends upon the amount and the complexity of the program's I/O,
and the degree of control which you require. For a simple stream
filter (read stdin, write stdout), lazy I/O is fine; for a program
which has more complex I/O behaviour, lazy I/O may become a nuisance
as the program grows more complex or as you need finer control.

If you just wanted a getContents replacement with a prompt, the
obvious solution would be to use unsafeInterleaveIO just to implement
that specific function.

The main problems with lazy I/O are the lack of control over ordering
(e.g. you can't delete the file until a stream has been closed, but
you may not be able to control how long the stream remains open), and
the inability to handle exceptions (the actual exception won't occur
until after e.g. getContents has returned).

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