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 <[EMAIL PROTECTED]> _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
