Unsafe hGetContents

[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 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
>
> It only addresses two known issues with lazy I/O, doesn't it?  It
> still injects input operations into pure code not in the IO monad.

While what you say is true, and I've complained about the same thing 
myself in the past, it turns out to be quite difficult to demonstrate 
the unsafety.

Try it!  Here's the rules.

   - write a program that gives different results when compiled with
     different optimisation flags only. (one exception: you're not
     allowed to take advantage of -fno-state-hack).

   - Using exceptions is not allowed (they're non-determinstic).

   - A difference caused by resources (e.g. stack overflow) doesn't
     count.

   - The only "unsafe" operation you're allowed to use is hGetContents.

   - You're allowed to use any other I/O operations, including from
     libraries, as long as they're not unsafe, and as long as the I/O
     itself is deterministic.

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!

Cheers,
	Simon