[Haskell-cafe] On the purity of Haskell

[Steve Horne]

On 30/12/2011 01:37, Chris Smith wrote:
> On Fri, 2011-12-30 at 00:44 +0000, Steve Horne wrote:
>> So, to resurrect an example from earlier...
>>
>> f :: Int ->  IO Int
>> f = getAnIntFromTheUser>>= \i ->  return (i+1)
> Did you mean  f :: IO Int ?  If not, then I perhaps don't understand
> your example, and your monad is not IO.  I'll continue assuming the
> former.
Oops - I meant...

f :: Int -> IO Int
f x = getAnIntFromTheUser >>= \i -> return (i+x)

Your version should be fine, only the lack of a parameter makes a 
superficial difference.

> I certainly agree that the GHC runtime system, and any other Haskell 
> implementation's runtime system as well, evaluates expressions (some 
> representation of them anyway), and does lots of destructive updates 
> to boot. This isn't at issue. What is at issue is whether to shoehorn 
> those effects into the language semantics as a side-effect of 
> evaluation (or equivalently, force evaluation of expressions to be 
> seen as an effect -- when you only allow for one of these concepts, 
> it's a silly semantic game as to which name you call it by), or to 
> treat effects as semantically first-class concepts in their own right, 
> different from the simplification of expressions into values. 
Well, we're playing a semantic game anyway. Treating effects as 
first-class concepts in themselves is fine, but IMO doesn't make Haskell 
pure.

>> If you do, we're back to my original model. The value returned by main
>> at compile-time is an AST-like structure wrapped in an IO monad
>> instance.
> Here you're introducing implementation detail here that's rather
> irrelevant to the semantics of the language.
Think of it as an analogy - using the terminology of compiler design. I 
might describe arithmetic in terms of an abacus too - it doesn't mean 
I'd only get those results if I used an abacus.

The implementation details don't matter - the behaviour of the program does.

> Purity isn't about the RTS implementation, which is of course plenty
> effectful and involves lots of destructive updates.  It's about the
> language semantics.
>
And the semantics of primitive IO actions *include* the run-time effects 
- those semantics are defined in the Haskell Report. For example...

    Computation hGetChar hdl reads a character from the file or channel
    managed by hdl.

If you have another meaning in mind for the word "semantics", well 
that's fine. As already discussed with "side effects", natural language 
is sadly ambiguous. It can be confusing, but it doesn't change the facts 
or the logic.

I don't know the first thing about denotational semantics, but I do know 
this - if you place run-time behaviour outside the scope of your model 
of program semantics, that's just a limitation of your model. It doesn't 
change anything WRT the program itself - it only limits the 
understanding you can derive using that particular model.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111230/2b984f2c/attachment.htm>