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.