Re: Proposal: end lazy IO results with errors/exceptions

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 wrote:

On Fri, Jul 25, 2014 at 12:05 AM, Eric Mertens 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries