Removing lazy IO? (Was: Re: Proposal: Stop enforcing single-writer-multi-reader file access)

newer
Testing containers outside of ghc...

older
Proposal: Stop enforcing...

Jason Dagit

8 Nov 2011 8 Nov '11

10:26 p.m.

On Tue, Nov 8, 2011 at 7:02 PM, Ian Lynagh wrote:

...

On Tue, Nov 08, 2011 at 01:07:23PM +0000, Duncan Coutts wrote:

...
We should take the same approach with openFile. Currently we have:

openFile :: FilePath -> IOMode -> IO Handle

I suggest changing the IOMode for a record of options which would include the IO mode (read/write/read-write/etc), and other things like file locking, default create permissions, create exclusive etc. Again, we'd use a default value and override extra options as necessary.

I've just reread the thread, and I think the best way forwards would be to make the original proposed change now, and for the above change to be proposed separately.

The other separate proposal that I would like to propose (at some time in the future) is a thorough removal of "lazy IO" from base. Or at least make it not available in the Prelude (ie., people have to ask for it if they want it). Perhaps this would require the support of Haskell'? Jason

Show replies by date

Ivan Lazar Miljenovic

8 Nov 8 Nov

11:03 p.m.

On 9 November 2011 14:26, Jason Dagit wrote:

...

The other separate proposal that I would like to propose (at some time in the future) is a thorough removal of "lazy IO" from base. Or at least make it not available in the Prelude (ie., people have to ask for it if they want it). Perhaps this would require the support of Haskell'?

Is this really necessary/desirable? I for one have made use of lazy I/O (though admittedly I typically do so now via lazy ByteString/Text values rather than String-based I/O). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Henning Thielemann

9 Nov 9 Nov

6:28 a.m.

On Wed, 9 Nov 2011, Ivan Lazar Miljenovic wrote:

...

On 9 November 2011 14:26, Jason Dagit wrote:

...
The other separate proposal that I would like to propose (at some time in the future) is a thorough removal of "lazy IO" from base. Or at least make it not available in the Prelude (ie., people have to ask for it if they want it). Perhaps this would require the support of Haskell'?

Is this really necessary/desirable? I for one have made use of lazy I/O (though admittedly I typically do so now via lazy ByteString/Text values rather than String-based I/O).

The behaviour is sometimes unexpected, e.g. in writeFile path . process =<< readFile path Further on it is hard to handle exceptions that occur during 'readFile' (getContents and so). Some time ago, I wrote the LazyIO monad that could encapsulate lazy I/O and thus may make it a bit safer. http://hackage.haskell.org/package/lazyio

Duncan Coutts

6:54 a.m.

On 9 November 2011 03:26, Jason Dagit wrote:

...

On Tue, Nov 8, 2011 at 7:02 PM, Ian Lynagh wrote:

...
On Tue, Nov 08, 2011 at 01:07:23PM +0000, Duncan Coutts wrote:

...
We should take the same approach with openFile. Currently we have:

openFile :: FilePath -> IOMode -> IO Handle

I suggest changing the IOMode for a record of options which would include the IO mode (read/write/read-write/etc), and other things like file locking, default create permissions, create exclusive etc. Again, we'd use a default value and override extra options as necessary.

I've just reread the thread, and I think the best way forwards would be to make the original proposed change now, and for the above change to be proposed separately.

The other separate proposal that I would like to propose (at some time in the future) is a thorough removal of "lazy IO" from base. Or at least make it not available in the Prelude (ie., people have to ask for it if they want it). Perhaps this would require the support of Haskell'?

Note that the issue of locking and the issue of lazy IO are mostly orthogonal. We still want locking to prevent accidental cases of concurrent reading and writing even if you're not using lazy IO. Duncan

Joachim Breitner

5:38 p.m.

New subject: Removing lazy IO?

Hi, Am Dienstag, den 08.11.2011, 19:26 -0800 schrieb Jason Dagit:

...

The other separate proposal that I would like to propose (at some time in the future) is a thorough removal of "lazy IO" from base. Or at least make it not available in the Prelude (ie., people have to ask for it if they want it). Perhaps this would require the support of Haskell'?

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. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

Edward Kmett

8:33 p.m.

New subject: Removing lazy IO?

I fail to see what is lazy about this O. It looks like regular O to me. =) On Wed, Nov 9, 2011 at 5:38 PM, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 08.11.2011, 19:26 -0800 schrieb Jason Dagit:

...
The other separate proposal that I would like to propose (at some time in the future) is a thorough removal of "lazy IO" from base. Or at least make it not available in the Prelude (ie., people have to ask for it if they want it). Perhaps this would require the support of Haskell'?

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.

Greetings, Joachim

-- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Joachim Breitner

10 Nov 10 Nov

3:01 a.m.

New subject: Removing lazy IO?

Hi, Am Mittwoch, den 09.11.2011, 20:33 -0500 schrieb Edward Kmett:

...

On Wed, Nov 9, 2011 at 5:38 PM, Joachim Breitner 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. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

Simon Marlow

7:36 a.m.

New subject: Removing lazy IO?

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 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. Cheers, Simon

Joachim Breitner

7:56 a.m.

New subject: Removing lazy IO?

Hi, Am Donnerstag, den 10.11.2011, 12:36 +0000 schrieb Simon Marlow:

...

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.

ah, got it. Thanks for the clarification! Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

4943

Age (days ago)

4944

Last active (days ago)

List overview

Download

8 comments

7 participants

participants (7)

Duncan Coutts
Edward Kmett
Henning Thielemann
Ivan Lazar Miljenovic
Jason Dagit
Joachim Breitner
Simon Marlow

Removing lazy IO? (Was: Re: Proposal: Stop enforcing single-writer-multi-reader file access)

tags

participants (7)