Proposal: end lazy IO results with errors/exceptions
David Feuer
david.feuer at gmail.com
Mon Jul 21 20:33:59 UTC 2014
As far as I can tell, the current behavior is that once the file is
closed, the string representing the contents essentially looks like
the part of the string whose spine was forced ++ zero or more
characters in the buffer ++ []
So a program relying on the current behavior would have to inspect the
stuff past the first (++) *after closing the file* and rely on it
being there, but it can't really rely on any details. That sort of
behavior seems like it belongs in the acme hierarchy.
On Mon, Jul 21, 2014 at 4:21 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> superficially¹ +1
>
> Joachim
>
> ¹ I like the idea, but can’t tell what the downsides are.
>
>
> Am Montag, den 21.07.2014, 16:16 -0400 schrieb David Feuer:
>> Currently,
>>
>> withFile "foo" hGetContents >>= putStrLn
>>
>> prints out an empty line, the better to confuse newbies.
>>
>> I propose modifying the lazyRead function in GHC.IO.Handle.Text that
>> currently reads
>>
>> lazyRead :: Handle -> IO String
>> lazyRead handle =
>> unsafeInterleaveIO $
>> withHandle "hGetContents" handle $ \ handle_ -> do
>> case haType handle_ of
>> ClosedHandle -> return (handle_, "")
>> SemiClosedHandle -> lazyReadBuffered handle handle_
>> _ -> ioException
>> (IOError (Just handle) IllegalOperation "hGetContents"
>> "illegal handle type" Nothing Nothing)
>>
>> to something like
>>
>> lazyRead :: Handle -> IO String
>> lazyRead handle =
>> unsafeInterleaveIO $
>> withHandle "hGetContents" handle $ \ handle_ -> do
>> case haType handle_ of
>> ClosedHandle -> return (handle_, error "Forcing the
>> result of a lazy read led to an attempt to read from a closed
>> handle.")
>> SemiClosedHandle -> lazyReadBuffered handle handle_
>> _ -> ioException
>> (IOError (Just handle) IllegalOperation "hGetContents"
>> "illegal handle type" Nothing Nothing)
>>
>> Ideally that error should instead be something to throw an imprecise
>> exception, but I don't know how to use those yet. I can't personally
>> see a way for this to break sane, working code, but the folks on #ghc
>> thought it should be discussed and debated on list.
>>
>> David Feuer
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> --
> Joachim Breitner
> e-Mail: mail at joachim-breitner.de
> Homepage: http://www.joachim-breitner.de
> Jabber-ID: nomeata at joachim-breitner.de
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
More information about the Libraries
mailing list