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. > > > > You can get lazy I/O to commute with other lazy I/O, and perhaps with > > some cunning arrangement of pipes (or something) that might be a way to > > solve the puzzle. Good luck! > > Oleg's example is quite close, don't you think? > > URL: http://www.haskell.org/pipermail/haskell/2009-March/021064.html
I didn't think that showed very much. He showed two different runs of two different IO programs where he got different results after having bypassed the safety switch on hGetContents. It shows that lazy IO is non-deterministic, but then we knew that. It didn't show anything was impure. As a software engineering thing, it's recommended to use lazy IO in the cases where the non-determinism has a low impact, ie where the order of the actions with respect to other actions doesn't really matter. When it does matter then your programs will probably be more comprehensible if you do the actions more explicitly. For example we have the shoot-yourself-in-the-foot restriction that you can only use hGetContents on a handle a single time (this is the safety mechanism that Oleg turned off) and after that you cannot write to the same handle. That's not because it'd be semantically unsound if those restrictions were not there, but it would let you write some jolly confusing non-deterministic programs. Duncan _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
