Memory allocation purity

[luka8088 via Digitalmars-d]

On 15.5.2014. 11:35, Jonathan M Davis via Digitalmars-d wrote:
> On Thu, 15 May 2014 10:14:48 +0200
> luka8088 via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> 
>> On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
>>> On Thu, 15 May 2014 05:51:14 +0000
>>> via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>>
>>>> Yep, purity implies memoing.
>>>
>>> No, it doesn't. _All_ that it means when a function is pure is that
>>> it cannot access global or static variables unless they can't be
>>> changed after being initialized (e.g. they're immutable, or they're
>>> const value types), and it can't call any other functions which
>>> aren't pure. It means _nothing_ else. And it _definitely_ has
>>> nothing to do with functional purity.
>>>
>>> Now, combined with other information, you _can_ get functional
>>> purity out it - e.g. if all the parameters to a function are
>>> immutable, then it _is_ functionally pure, and optimizations
>>> requiring functional purity can be done with that function. But by
>>> itself, pure means nothing of the sort.
>>>
>>> So, no, purity does _not_ imply memoization.
>>>
>>> - Jonathan M Davis
>>>
>>
>> Um. Yes it does. http://dlang.org/function.html#pure-functions
>> "functional purity (i.e. the guarantee that the function will always
>> return the same result for the same arguments)"
>>
>> The fact that it should not be able to effect or be effected by the
>> global state is not a basis for purity, but rather a consequence.
>>
>> Even other sources are consistent on this matter, and this is what
>> purity by definition is.
>>
> 
> The reread the paragraph at the top of the section of the documentation
> that you linked to:
> 
> "Pure functions are functions which cannot access global or static,
> mutable state save through their arguments. This can enable
> optimizations based on the fact that a pure function is guaranteed to
> mutate nothing which isn't passed to it, and in cases where the
> compiler can guarantee that a pure function cannot alter its arguments,
> it can enable full, functional purity (i.e. the guarantee that the
> function will always return the same result for the same arguments)."
> 
> That outright says that pure only _can_ enable functional purity - in
> particular when the compiler is able to guarantee that the function
> cannot mutate its arguments. pure itself however means nothing of the
> sort. The fact that pure functions cannot access global state _is_ the
> basis for functional purity when combined with parameters that
> arguments cannot be mutated.

I am aware of weak/strong purity. I am only talking about strong purity now.

To quote bearophile:

bool randomBit() pure nothrow @safe {
    return (new int[1].ptr) > (new int[1].ptr);
}
void main() {}

"Pure functions are functions which cannot access global or static,
mutable state save through their arguments." - no objections here

"This can enable optimizations based on the fact that a pure function is
guaranteed to mutate nothing which isn't passed to it, and in cases
where the compiler can guarantee that a pure function cannot alter its
arguments, it can enable full, functional purity (i.e. the guarantee
that the function will always return the same result for the same
arguments)." - no arguments where passed to the function, it should
always return the same result

> 
> If you get hung up on what the concept of functional purity is or what
> you thought pure was before using D, then you're going to have a hard
> time understanding what pure means in D. And yes, it's a bit weird, but
> it comes from the practical standpoint of how to make functional purity
> possible without being too restrictive to be useful. So, it really
> doesn't matter what other sources say about what purity means. That's
> not what D's pure means. D's pure is just a building block for what
> purity normally means. It makes it so that the compiler can detect
> functional purity and then optimize based on it, but it doesn't in and
> of itself have anything to do with functional purity.
> 
> If the documentation isn't getting that across, then I guess that it
> isn't clear enough. But I would have thought that the part that said
> "and in cases where the compiler can guarantee that a pure function
> cannot alter its arguments, it can enable full, functional purity"
> would have made it clear that D's pure is _not_ functionally pure by
> itself. The first part of the paragraph says what pure really means:
> "Pure functions are functions which cannot access global or static,
> mutable state save through their arguments." Everything else with
> regards to functional purity is derived from there, but in and of
> itself, that's _all_ that the pure attribute in D means.
> 
> See also: http://klickverbot.at/blog/2012/05/purity-in-d/
> 
> - Jonathan M Davis
> 

Yeah, it does not seem to be clear enough.

It comes down to two simple questions:
  - should you be able to make a strong pure rand() function i D?
  - if not, why?

My answer would be: no, because the result should always be the same.

Of course I could be wrong, but my understanding of it fits with what
the docs say. I think that answering this questions would clarify a lot!