Re: [Haskell-cafe] On the purity of Haskell

Sorry for the delay. I've written a couple of long replies already, and both times when I'd finished deleting all the stupid stuff there was nothing left - it seems I'm so focussed on my own view, I'm struggling with anything else today. Maybe a third try... On 28/12/2011 19:38, AUGER Cédric wrote:

Le Wed, 28 Dec 2011 17:39:52 +0000, Steve Horne a écrit :

...

This is just my view on whether Haskell is pure, being offered up for criticism. I haven't seen this view explicitly articulated anywhere before, but it does seem to be implicit in a lot of explanations - in particular the description of Monads in SBCs "Tackling the Awkward Squad". I'm entirely focused on the IO monad here, but aware that it's just one concrete case of an abstraction.

IO monad doesn't make the language impure for me, since you can give another implementation which is perfectly pure and which has the same behaviour (although completely unrealistic):

Now how would this work? In a first time, you load all your system file before running the program (a "side-effect" which does not modify already used structures; it is just initialization), then you run the program in a perfectly pure way, and at the end you commit all to the system file (so you modify structures the running program won't access as it has terminated). I don't see how interactivity fits that model. If a user provides input in response to an on-screen prompt, you can't do all the input at the start (before the prompt is delayed) and you can't do all the output at the end.

Other than that, I'm OK with that. In fact if you're writing a compiler that way, it seems fine - you can certainly delay output of the generated object code until the end of the compilation, and the input done at the start of the compilation (source files) is separate from the run-time prompt-and-user-input thing. See - I told you I'm having trouble seeing things in terms of someone elses model - I'm back to my current obsession again here.

In Haskell, 'hGetChar h>>= \c -> hPutChar i' always has the same value, but 'trans (hGetChar h>>= \c -> hPutChar i) (IO_ A)' 'trans (hGetChar h>>= \c -> hPutChar i) (IO_ B)' may have different values according to A and B.

In C, you cannot express this distinction, since you only have: 'read(h,&c, 1); write(i,&c, 1);' and cannot pass explicitely the environment. Agreed. Haskell is definitely more powerful in that sense.