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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
