Removing lazy IO?

Simon Marlow marlowsd at
Thu Nov 10 13:36:25 CET 2011

On 10/11/2011 08:01, Joachim Breitner wrote:
> Hi,
> Am Mittwoch, den 09.11.2011, 20:33 -0500 schrieb Edward Kmett:
>> On Wed, Nov 9, 2011 at 5:38 PM, Joachim Breitner
>> <mail at>  wrote:
>>          I very much like the lazy O in lazy IO, e.g. with this real-life code
>>          line:
>>             hPutStrLn stderr $ "Out of " ++ show (IxS.size (binaries unstable `IxS.union` binaries testing)) ++ " binary packages, " ++ show (IxS.size unmod) ++ " are unmodified, but
>>          " ++ show (IxS.size affected) ++ " are possibly affected."
>>          Thanks to lazy IO, I get a very nice feedback about what the code is
>>          doing right now, and how long the various values take to calculate.
>> I fail to see what is lazy about this O. It looks like regular O to
> me. =)
> When it is run, it will print
> Out of
>          then wait for a while, then print a number and the next text
> Out of 123455 binary packages,
>          then wait for a while, the print the next number
> Out of 123455 binary packages, 4223 are unmodified, but
>          then wait for a while and then print the rest:
> Out of 123455 binary packages, 4223 are unmodified, but 213213 are
> possibly affected.
> Isn’t that due to lazy IO? print starts printing the string while it is
> evaluated, instead of evaluating the full string and printing it in one
> system call.

It's not what we traditionally refer to as "lazy IO".  It is lazy, but 
it is not injecting side-effects into pure compuations.  You can tell 
that it isn't problematic by the fact that you can implement hPutStrLn 
yourself in terms of hPutChar, there's no ned for unsafeInterleaveIO.

The problematic lazy I/O is really just hGetContents and getContents. 
So it's really just lazy I, not lazy I/O.


More information about the Libraries mailing list