|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-21 12:21:13
"David Bergman" <davidb_at_[hidden]> writes:
> Dave wrote:
>
>> "David Bergman" <davidb_at_[hidden]> writes:
>>
>> > It has to do with purity, that Haskell is a pure language
>> in the sense
>> > of an expression ALWAYS evaluating to the same value, so
>> that the same
>> > exact expression can be substituted for that computed value
>> wherever, whenever.
>>
>> Even I can tell that has no bearing on side-effects, though:
>>
>> int z;
>> int f(int x) { return z = x; }
>>
>> f(y) is always y for any y
>> still, it has side-effects.
>
> Good, than that particular expression is transparent, in the pure sense. If
> you manage to have *all other* expressions being transparent as well, you
> have a pure piece of code! (That would of course mean that the side-effect
> in your assignment is *never* exposed...)
>
> "Side effect" indicates that it should affect the visible parts of the
> execution, just like in the operational abstract machine in the C++
> language, does it not? Writing to a memory cell which is never read is
> hardly a side-effect, is it?
It depends if that memory is mapped to an output channel which
doesn't affect the values in the program. I almost wrote:
int f(int x) { std::cout << x; return x; }
Just imagine that cout didn't have a value that could change
detectably.
That said, we need the same fudge about external side-effects in
order to describe the exception-safety guarantees. It's a nit.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk