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

21 Jul 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
 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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
--
Joachim Breitner
  e-Mail: mail@joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata@joachim-breitner.de
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries