Re: Unsafe hGetContents

2009-10-20 Thread Simon Marlow
On 10/10/2009 18:59, Iavor Diatchki wrote: Hello, well, I think that the fact that we seem to have a program context that can distinguish f1 from f2 is worth discussing because I would have thought that in a pure language they are interchangable. The question is, does the context in Oleg's

Re: Unsafe hGetContents

2009-10-20 Thread Duncan Coutts
On Tue, 2009-10-20 at 13:58 +0100, Simon Marlow wrote: Duncan has found a definition of hGetContents that explains why it has surprising behaviour, and that's very nice because it lets us write the compilers that we want to write, and we get to tell the users to stop moaning because the

Re: Unsafe hGetContents

2009-10-20 Thread Duncan Coutts
On Tue, 2009-10-20 at 15:45 +0100, Simon Marlow wrote: I've not yet seen anyone put forward any practical programs that have confusing behaviour but were not written deliberately to be as wacky as possible and avoid all the safety mechanism. The standard use case for hGetContents is

Re: Unsafe hGetContents

2009-10-12 Thread Simon Marlow
On 11/10/2009 09:26, Florian Weimer wrote: * Simon Marlow: Oleg's example is quite close, don't you think? URL: http://www.haskell.org/pipermail/haskell/2009-March/021064.html Ah yes, if you have two lazy input streams both referring to the same underlying stream, that is enough to

Re: Unsafe hGetContents

2009-10-11 Thread Florian Weimer
* Simon Marlow: Oleg's example is quite close, don't you think? URL: http://www.haskell.org/pipermail/haskell/2009-March/021064.html Ah yes, if you have two lazy input streams both referring to the same underlying stream, that is enough to demonstrate a problem. As for whether Oleg's

Re: Unsafe hGetContents

2009-10-11 Thread Isaac Dupree
Hmm, Don't you think forkIO deserves some of the same complaints as unsafeInterleaveIO? Things happen in a nondeterministic order! I think what irritates us about unsafeInterleaveIO is that it's IO that tinkers with the internals of the Haskell evaluation system. The OS can't do it: in a C

Re: Unsafe hGetContents

2009-10-10 Thread Iavor Diatchki
Hello, well, I think that the fact that we seem to have a program context that can distinguish f1 from f2 is worth discussing because I would have thought that in a pure language they are interchangable. The question is, does the context in Oleg's example really distinguish between f1 and f2?

Re: Unsafe hGetContents

2009-10-06 Thread Simon Marlow
On 03/10/2009 19:59, Florian Weimer wrote: * Nicolas Pouillard: Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side

Re: Unsafe hGetContents

2009-10-06 Thread Nicolas Pouillard
Excerpts from Simon Marlow's message of Tue Oct 06 14:59:06 +0200 2009: On 03/10/2009 19:59, Florian Weimer wrote: * Nicolas Pouillard: Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009: Are there any plans to get rid of hGetContents and the semi-closed handle

Re: Unsafe hGetContents

2009-10-06 Thread Simon Marlow
On 06/10/2009 14:18, Nicolas Pouillard wrote: Excerpts from Simon Marlow's message of Tue Oct 06 14:59:06 +0200 2009: On 03/10/2009 19:59, Florian Weimer wrote: * Nicolas Pouillard: Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009: Are there any plans to get rid of

Re: Unsafe hGetContents

2009-10-06 Thread Duncan Coutts
On Tue, 2009-10-06 at 15:18 +0200, Nicolas Pouillard wrote: The reason it's hard is that to demonstrate a difference you have to get the lazy I/O to commute with some other I/O, and GHC will never do that. If you find a way to do it, then we'll probably consider it a bug in GHC.

Re: Unsafe hGetContents

2009-09-21 Thread Simon Marlow
On 16/09/2009 21:17, Florian Weimer wrote: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the transformations which are

Re: Unsafe hGetContents

2009-09-21 Thread Simon Marlow
On 17/09/2009 13:58, Nicolas Pouillard wrote: Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern

Re: Unsafe hGetContents

2009-09-21 Thread Nicolas Pouillard
Excerpts from Simon Marlow's message of Mon Sep 21 11:41:38 +0200 2009: On 16/09/2009 21:17, Florian Weimer wrote: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern

Re: Unsafe hGetContents

2009-09-21 Thread Nicolas Pouillard
Excerpts from Simon Marlow's message of Mon Sep 21 11:52:41 +0200 2009: On 17/09/2009 13:58, Nicolas Pouillard wrote: Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime?

Re: Unsafe hGetContents

2009-09-17 Thread Nicolas Pouillard
Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the

Re: Unsafe hGetContents

2009-09-16 Thread Don Stewart
fw: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the transformations which are expected to be valid in a pure language.)

Re: Unsafe hGetContents

2009-09-16 Thread Florian Weimer
* Don Stewart: fw: Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the transformations which are expected to be valid in a