Re: Unsafe hGetContents
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? > >> > >> (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.) > > > > Would you consider something like [1] as an acceptable replacement? > > > > [1]: http://hackage.haskell.org/package/safe-lazy-io > > I rater like this as a workaround for the most common practical problems > with lazy I/O, those of resource control. > It doesn't address the deeper > concern that lazy I/O requires a particular evaluation order and is > therefore a bit warty as a language feature When using safe-lazy-io we no longer rely (or a lot less) on the evaluation order (assuming you mean the order of side-effects). Since the way of combining the different inputs is statically chosen by user. > - implementing lazy I/O > properly in GHC's parallel mutator was somewhat tricky. I'm not of the > opinion that we should throw out lazy I/O, but it's still a problematic > area in Haskell. Maybe the 'unsafeGetContents' feature required by a safe-lazy-io would be less problematic, in particular it does not have to ignore exceptions. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Unsafe hGetContents
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 > > matching, stricly speaking invalidating most of the transformations > > which are expected to be valid in a pure language.) > > There is no current proposal for this, no. Feel free to start one; > information about the process for Haskell Prime proposals is here > > http://hackage.haskell.org/trac/haskell-prime/wiki/Process An alternate proposition (instead of removing it) would to to move it to System.IO.Unsafe. -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Unsafe hGetContents
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 matching, stricly speaking invalidating most of the transformations which are expected to be valid in a pure language.) Would you consider something like [1] as an acceptable replacement? [1]: http://hackage.haskell.org/package/safe-lazy-io I rater like this as a workaround for the most common practical problems with lazy I/O, those of resource control. It doesn't address the deeper concern that lazy I/O requires a particular evaluation order and is therefore a bit warty as a language feature - implementing lazy I/O properly in GHC's parallel mutator was somewhat tricky. I'm not of the opinion that we should throw out lazy I/O, but it's still a problematic area in Haskell. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Unsafe hGetContents
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 expected to be valid in a pure language.) There is no current proposal for this, no. Feel free to start one; information about the process for Haskell Prime proposals is here http://hackage.haskell.org/trac/haskell-prime/wiki/Process Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime