Resources/papers on lazy I/O

Hi all, I recently finished up writing streaming facilities via libarchive bindings and lazy bytestrings. It ended up working nicely - reading from a file lazily and then unpacking the archive was more efficient in time + allocations than reading the file all at once. That got me thinking - what exactly is wrong with lazy I/O? I've seen Oleg Kiselyov's paper (http://okmij.org/ftp/Haskell/#lazyIO-not-True) and I've run into issues myself (basically the issue here: https://stackoverflow.com/questions/31342012/read-and-writing-to-file-in-has...), but none of those seem so pathological - the second issue could be better resolved with linear types! Are the any explanations of why Haskell *does* use lazy I/O? Laziness allows symmetries between values and generators of values - surely it is not *that* immoral to enforce this even in the IO monad? Cheers, Vanessa McHale

Am 28.03.19 um 19:26 schrieb Vanessa McHale:
That got me thinking - what exactly is wrong with lazy I/O? I've seen Oleg Kiselyov's paper (http://okmij.org/ftp/Haskell/#lazyIO-not-True) and I've run into issues myself (basically the issue here: https://stackoverflow.com/questions/31342012/read-and-writing-to-file-in-has...), but none of those seem so pathological - the second issue could be better resolved with linear types!
As far as I recall, IO was the nasty loophole in Haskell initially, and after lots of ugly hackery and living with the pain, various approaches emerged. Today's IO system was one of the, and there were two contenders. IO won because it was the first one to become useful, and while at least one of the others made it to the proof-of-concept stages, IO had started to mature already and the contender never managed to get much mind share. So... it's part historical accident, part "nobody had a better idea at the time". Which means that there could well be better alternatives, but it's unclear how to judge whether some alternative is really better, so even people with an interest in the field tend to research on other topics. Regards, Jo

The basic problem is just that it's error prone when you're doing things that are non-trivial wrt the lifetime of the file. Part of the original motivation for Haskell's "purity" was that lazy evaluation and side-effects are hard to think about. In languages that allow it, "don't mix laziness and effects" is a bit of common folk-wisdom. See e.g: https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects If I'm writing a simple program that just reads in some data, does stuff, and spits it back out, I usually don't stress about it. But for long running programs, file descriptor leaks can be a problem, and between that and needing to be async-exception safe, the usual resource management strategies in Haskell make the whole thing pretty dicey. Quoting Vanessa McHale (2019-03-28 14:26:22)
the second issue could be better resolved with linear types!
How would this work? Not sure I follow.

I wrote about this in the context of Miranda some time ago … https://kar.kent.ac.uk/20889/1/interactive_thompson.pdf https://kar.kent.ac.uk/20889/1/interactive_thompson.pdf Simon
On 28 Mar 2019, at 18:51, Ian Denhardt
wrote: The basic problem is just that it's error prone when you're doing things that are non-trivial wrt the lifetime of the file. Part of the original motivation for Haskell's "purity" was that lazy evaluation and side-effects are hard to think about. In languages that allow it, "don't mix laziness and effects" is a bit of common folk-wisdom. See e.g:
https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects
If I'm writing a simple program that just reads in some data, does stuff, and spits it back out, I usually don't stress about it. But for long running programs, file descriptor leaks can be a problem, and between that and needing to be async-exception safe, the usual resource management strategies in Haskell make the whole thing pretty dicey.
Quoting Vanessa McHale (2019-03-28 14:26:22)
the second issue could be better resolved with linear types!
How would this work? Not sure I follow. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson@kent.ac.uk mailto:s.j.thompson@kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt http://www.cs.kent.ac.uk/~sjt
participants (4)
-
Ian Denhardt
-
Joachim Durchholz
-
Simon Thompson
-
Vanessa McHale