Is hGetLine lazy like hGetContents? And what about this todo item?
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... 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... 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? Thanks, Jason
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...
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...
Correct: it is not lazy, and it is safe to use inside withFile.
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. Cheers, Simon
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...
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...
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. Thanks, Jason
On Thu, Mar 25, 2010 at 6:07 PM, Jason Dagit
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.
Making library patches is not that hard. Have a look at the following to see how to setup your machine for building GHC and the libraries: http://hackage.haskell.org/trac/ghc/wiki/Building When you've made your patch try to follow the library submission procedure as described in: http://haskell.org/haskellwiki/Library_submissions Good luck, Bas
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...
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...
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
On Thu, 2010-03-25 at 21:38 +0000, Simon Marlow wrote:
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...
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...
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!
I received your email about 5 minutes too late :) Feel free to delete my library submission ticket. Thanks, Jason
participants (3)
-
Bas van Dijk -
Jason Dagit -
Simon Marlow