purity and memory allocations/pointers

[Timon Gehr]

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.)