On 5/14/2014 5:56 PM, Meta wrote:
> On Thursday, 15 May 2014 at 00:50:06 UTC, Walter Bright wrote:
>> On 5/14/2014 5:03 PM, Meta wrote:
>>> Allocating memory through new and malloc should always be pure, I think, because
>>> failure either returns null in malloc's case,
>>
>> malloc cannot be pure if, with the same arguments, it returns null sometimes
>> and not other times.
>>
>>
>>> or throws an error in new's case.
>>
>> A non-recoverable error.
>>   ^^^^^^^^^^^^^^^
>
> If we pretend that there's infinite memory, then malloc will never return null.

And what happens when malloc returns null?

On Thursday, 15 May 2014 at 02:49:28 UTC, Adam Sakareassen via Digitalmars-d wrote:
> The more D allows 'pure' functions to diverge from functional purity the less relevant the flag is for compiler optimisations.
...
> By the same reasoning cacheability is important.  A pure function might be called within a loop with a parameter that is not altered during the loop.  If the compiler knows the function is pure, it can perform the calculation before the loop and simply reuse the cached result for each iteration.

Yep, purity implies memoing. Malloc and new are not pure because they return objects that can be differentiated by address.  Malloc and new are random generators in that sense. So to make them pure you will have to put a ban on taking address, comparing address etc on the objects...

However mmap to a fixed address is pure if it throws an exception on failure because the exception bypass the call site of the pure function (pure functions should not catch side effect exceptions).

Returning null does not make a function impure. Pure functions may return bottom (like division by zero).

Pure in D seems pointless to me.

On Thursday, 15 May 2014 at 05:51:16 UTC, Ola Fosheim Grøstad wrote:
> However mmap to a fixed address is pure if it throws an exception on failure because the exception bypass the call site of the pure function (pure functions should not catch side effect exceptions).

This of course presumes a transactional view, that the transaction is the context of purity and that flaws in purity unwinds all changes and thus abort the transaction (the try block).

If the result of a series of pure function calls can be used to flip a coin within a transaction, then those functions cannot be considered pure in any meaningful sense.

Ola Fosheim Grøstad:

> Pure in D seems pointless to me.

If you start using pure in D you see it's like const: it allows you to remove certain kinds of your mistakes from the code, and it makes it more easy to reason about the code.

You can use mutability inside a strongly pure function. This is a very good.

Bye,
bearophile

Ola Fosheim Grøstad:

> If the result of a series of pure function calls can be used to flip a coin within a transaction, then those functions cannot be considered pure in any meaningful sense.

A little example of D purity (this compiles):


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


Bye,
bearophile

On Thursday, 15 May 2014 at 06:24:30 UTC, bearophile wrote:
> If you start using pure in D you see it's like const: it allows you to remove certain kinds of your mistakes from the code, and it makes it more easy to reason about the code.

As lint like functionality, yes.

> You can use mutability inside a strongly pure function. This is a very good.

Local mutability does not affect purity, it is the pre and post conditions at the call site that matters.

On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
> A little example of D purity (this compiles):

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

Yes, and then you may as well allow a random generator with private globals. Because memoing is no longer sound anyway.

On Thu, 15 May 2014 05:51:14 +0000
via Digitalmars-d <digitalmars-d@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

On Thursday, 15 May 2014 at 06:59:08 UTC, Jonathan M Davis via Digitalmars-d wrote:
> And it _definitely_ has nothing to do with functional purity.

Which makes it pointless and misleading.

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

No, you can't say it is functionally pure if you can flip a coin with a pure function. To do that you would need a distinction between "prove pure" and "assume pure" as well as having immutable reference types that ban identity comparison.

> So, no, purity does _not_ imply memoization.

It should, or use a different name.

And mutating through parameters does not affect functional purity in the theoretical sense if the function holds the only reference to it. It is comparable to taking one value and returning a new version of it.

Rigor is important in language design. If you cannot say ALWAYS, then the compiler will have to assume NEVER.