Resources/papers on lazy I/O

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Resources/papers on lazy I/O

Vanessa McHale

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-haskell), 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


_______________________________________________
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.

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Resources/papers on lazy I/O

Joachim Durchholz
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-haskell),
> 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
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Resources/papers on lazy I/O

Ian Denhardt
In reply to this post by Vanessa McHale
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.
Reply | Threaded
Open this post in threaded view
|

Re: Resources/papers on lazy I/O

Simon  Thompson
 I wrote about this in the context of Miranda some time ago …


Simon


On 28 Mar 2019, at 18:51, Ian Denhardt <[hidden email]> 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
[hidden email] | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt


_______________________________________________
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.