[Haskell-cafe] Re: Is hGetLine lazy like hGetContents? And what about this todo item?

[Simon Marlow]

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