Proposal: end lazy IO results with errors/exceptions

[David Feuer]

That's going a little too far. It's safe to close a handle once *you*
know the lazy IO has been done. The burden is on you, unfortunately.
I'm just hoping with this proposal to make it more likely to find out
where you've messed up when things don't work.

Safe:
   Open handle
   Read lazily from handle
   Perform output using lazily read input
   Close handle
Safe:
   Open handle
   Read lazily from handle
   Produce a value and ensure that as much of it as you will need has
been forced
   Close handle
   Return value
Unsafe:
   Open handle
   Read lazily from handle
   Produce a value without ensuring that the parts you need have been forced
   Close handle
   Return value

On Fri, Jul 25, 2014 at 11:36 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Fri, Jul 25, 2014 at 12:05 AM, Eric Mertens <emertens at gmail.com> wrote:
>>
>> In any case, file descriptors are precious and it would make sense to
>> hClose the file when you're done with it rather than wait and hope that the
>> GC gets to closing your file.
>>
>> With this change we'd be introducing asynchronous minefields into code
>> that don't need to exist.
>
>
> hGetContents *is* an asynchronous minefield. This is attempting to make it
> less so.
>
> As for hClose, currently it is erroneous to hClose a handle on which
> hGetContents has been done; you *cannot* hClose it at any point after you
> have used hGetContents without losing data, as there is no way to know when
> it is safe/correct to do so. If you believe otherwise, you may not
> understand how it is implemented. (unsafeInterleaveIO is "unsafe" for a
> reason.)
>
> --
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>