On 08/04/2013 06:37 AM, Meta wrote:
On Sunday, 4 August 2013 at 02:05:55 UTC, Timon Gehr wrote:
no variables are being modified.
Which I didn't claim. A reference is dereferenced and the contents of
the referenced slot are replaced. Then the reference is dereferenced
again to read the modified value out.
I'm confused about what your point is now. Are you trying to convince me
that dereferencing p and modifying the value it points to are
side-effect free? Of course you can do it in Haskell with some wizardry,
but D doesn't do any of that.
...
Weak purity is actually superficially similar to state transformers in
Haskell.
Haskell only simulates side-effects
What tells you that D does not 'simulate' mutable state?
I see what you're getting at. I thought I had a good answer before I
really thought about your question. I can't think of any way to prove
that a language is not simply simulating mutable state off the top of my
head. Do you actually have an answer to this question, or were you just
making a point?
...
I think you cannot tell, and hence it is questionable whether simulated
side effects are different from real side effects. Basically it is an
implementation detail. The side effects occurring in that Haskell
expression are as real as those occurring in D. (GHC actually implements
this as updating a mutable memory location under the hood, but it does
not really matter.)
with monads,
What is done to main behind the scenes in order to execute the program
is most definitely side-effecting.
I agree with you, but that is done by the runtime in a safe way and is
mostly out of the user's hands.
...
I'd agree with 'mostly safe'. We don't/can't know how the real world
works, and it has inherent limitations not shared by idealized
programming languages. (and vice versa!)
(i.e., the academic definition of purity).
I wouldn't go that far.
Perhaps that may go too far, as academics love to obfuscate topics with
a bunch of extraneous cruft,
I take issue with this statement. I meant, I wouldn't assume 'the
academic definition of purity' is a thing.
I don't know what you mean by this. By academic definition, I meant the
definition of functional purity that is generally agreed-upon by the CS
academia.
...
Me too. I just don't think there is a notion of functional purity
applying equally well to all programming languages.
Eg. in Spec# [Pure] precludes heap allocations IIRC, but pure functional
languages can most definitely allocate heap storage when evaluating an
expression.
but the fact remains that purity means:
1. No modification of local or global state (side-effects)
2. No dependence on global mutable state.
What does this statement quantify over? Eg, where is the abstraction
boundary?
Again, can you be more clear?
My meaning was that for a function to be
pure, in a functional programming sense, it must adhere to these rules.
At the lowest level of abstraction, no function call will adhere to
these rules, since the machine changes its state.
Then there is the memory allocator that carries around global state. The
perception of whether or not this allocator is pure will likely depend
on how much access to this global state is given to the user program.
etc.
How pure or impure a given operation is in a given language will
sometimes depend on the entire language design.
In order to resolve the topic, I guess it is useful to state which
properties of 'pure' functions, we want to rely on. (Such properties are
also easier to translate between programming languages, but this is
still moot.)
