On 25/03/10 17:07, Jason Dagit wrote:
On Thu, 2010-03-25 at 16:13 +0000, Simon Marlow wrote:
On 25/03/2010 15:40, Jason Dagit wrote:
Hello,
I was trying to figure out if hGetLine is safe to use inside of
withFile. Specifically, I want to return the line I read and use it
later, without inspecting it before withFile calls hClose.
If you want to understand the concern I have, look here:
http://www.haskell.org/haskellwiki/Maintaining_laziness#Input_and_Output
There is a bit of explanation showing that hGetContents can be
problematic with withFile.
I can tell from reading the source of hGetContents that it uses
unsafeInterleaveIO so this make sense to me why that wiki page talks
about hGetContents:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO-Handle-Text.html#hGetContents
When I read the source of hGetLine, it is less clear to me if I need to
be concerned. I believe it is not lazy in the sense of lazy IO above.
Could someone else please comment?
http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO-Handle-Text.html#hGetLine
Correct: it is not lazy, and it is safe to use inside withFile.
Great! I did a few simple tests in GHCi and it seemed safe, but I
wanted to be extra prudent. Thanks.
Then I notice this 'todo' item in the description:
-- ToDo: the unbuffered case is wrong: it doesn't lock the handle for
-- the duration.
The code itself looks to me like it only handles the buffered case.
Perhaps this todo is obsolete and needs to be removed? If it's not
obsolete, do we need to create a ticket for this?
Well spotted, that comment is out of date and wrong. There used to be a
version of hGetLine written in terms of hGetChar which was used when the
Handle was unbuffered, but I think I removed it in the recent rewrite.
What is the next step for getting rid of the obsolete comment? Did you
already nuke it? If not, I could try to get a copy of the ghc repo and
see if I can figure out the right protocol for submitting a patch.
Already nuked in my working tree, it'll filter through into the repo in
due course. The library submission process would be way overkill for that!
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
