Proposal: end lazy IO results with errors/exceptions

[Dan Doel]

What is an example of a use case where relying on the current behavior
would be a good thing?

For an exception to happen, one has to force more than what was already
forced when the handle was closed. The vast majority of instances of
this---as far as I can tell---are people immediately closing handles
they've lazily read from, and an exception is probably more informative
than the empty input they currently get.

For correct-given-the-current-spec code to break, it seems like it would
have to be relying on one part of the code forcing the input before closing
to be an implicit signal to another part of the code that inspects the
input after the closing. But I don't see a reason to encourage/support that
kind of design.

I'm in favor of this change, in case that wasn't obvious. :)



On Fri, Jul 25, 2014 at 12:05 AM, Eric Mertens <emertens at gmail.com> wrote:

> -1
>
> I think that this change would make otherwise reasonable uses of
> hGetContents on large files more likely to end with an exception. It seems
> perfectly reasonable to use hGetContents to stream data from a either a
> large source or an infinite source (say a pipe or socket or /dev/urandom).
> Perhaps you're streaming those bytes into another form, who knows. 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.
>
>
> On Thu, Jul 24, 2014 at 8:50 PM, John Wiegley <johnw at newartisans.com>
> wrote:
>
>> +1 from me.
>>
>> John
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> --
> Eric Mertens
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140725/a2dbca39/attachment-0001.html>