On Tuesday, 9 April 2013 at 08:33:53 UTC, Manu wrote:
> On 9 April 2013 18:04, Dicebot <m.strashun@gmail.com> wrote:
>
>> On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
>>
>>> Are you saying the example above is not actually valid code?
>>>
>>> struct Foo {
>>>     int a = 0;
>>>     pure int bar( int n ) { // Weakly pure
>>>         a += n;
>>>         return a;
>>>     }
>>> }
>>>
>>> That's not pure. Call it twice with the same args, you'll different
>>> answers. How can that possibly be considered pure in any sense?
>>> And it's useless in terms of optimisation, so why bother at all? What does
>>> it offer?
>>>
>>
>> It is valid code. It is "weak pure". "pure' keyword means both
>> "strong pure" or "weak pure" depending on function body. Crap.
>>
>
> How can 'weak pure' reasonably be called any kind of 'pure'? It's not pure
> at all. The function returns a completely different result when called
> twice.

The returned results are different because the parameters you are calling it with are different. Note that for member functions 'this' is also passed implicitly as a ref parameter. On the second call it has different value than on the first call. If you don't want to allow mutating 'this' you should make the function const, thus making the implicit 'this' parameter const ref.

On 2013-04-09 12:24, Timon Gehr wrote:

> static -> (no suggestion)

"static" has quite a lot of overloads as well.

-- 
/Jacob Carlborg

On 04/09/2013 01:27 PM, Manu wrote:
> ...
>
> The only optimisation possibility is for strong pure functions that are
> also nothrow, right?  Was that the conditions for pure function refactoring?

No, strongly pure functions will always throw the same classes of exceptions when called with the same arguments. Therefore, with some flow-analysis, common subexpression elimination can apply to strongly pure functions which are not nothrow.

Eg, given int foo(int)pure;, the transformation from

a = foo(2);
b = foo(2);

to

a = foo(2);
b = a;

is valid.

On 04/09/2013 01:39 PM, Timon Gehr wrote:
> On 04/09/2013 01:27 PM, Manu wrote:
>> ...
>>
>> The only optimisation possibility is for strong pure functions that are
>> also nothrow, right?  Was that the conditions for pure function
>> refactoring?
>
> No, strongly pure functions will always throw the same classes of
> exceptions when called with the same arguments. Therefore, with some
> flow-analysis, common subexpression elimination can apply to strongly
> pure functions which are not nothrow.
>
> Eg, given int foo(int)pure;,

and int a,b;,

> the transformation from
>
> a = foo(2);
> b = foo(2);
>
> to
>
> a = foo(2);
> b = a;
>
> is valid.

On Tuesday, 9 April 2013 at 10:24:45 UTC, Timon Gehr wrote:
> On 04/09/2013 10:33 AM, Manu wrote:
>> ...
>>
>> How can 'weak pure' reasonably be called any kind of 'pure'? It's not
>> pure at all. The function returns a completely different result when
>> called twice. That's the definition of not-pure.
>
> (Actually this is not the definition of impure.)
>
> In D, 'pure' forbids reading or writing of mutable static variables.
>
>> I suggest that no D language newbie would ever reasonably expect that
>> behaviour.
>
> Sure. Many keyword choices in D are unhelpful for newbies, or technically wrong.
>
> enum   -> const
> catch  -> handle
> do     -> repeat
> for    -> (no suggestion)
> const  -> readonly
> inout  -> (no suggestion)
> lazy   -> byname
> pure   -> (no suggestion)
> static -> (no suggestion)
> struct -> (no suggestion)
> throw  -> raise / signal
> union  -> (no suggestion)

for -> loop?

On Tue, 09 Apr 2013 13:10:16 +0200, Artur Skawina <art.08.09@gmail.com> wrote:

> A function that both directly depends on global mutable state (and
> modifies it) can hardly be called pure. Can you (anybody) give a
> D "pure" definition that allows for the program that I've posted
> and still makes "pure" useful?

Functions that are pure may only mutate mutable state explicitly passed
to them, or created within.

There. That's basically all there is to D's pure. From this definition
arise some useful properties, e.g. that a function whose parameters are
all immutable or implicitly castable to immutable, is referentially
transparent.

-- 
Simen

On 04/09/2013 01:26 PM, Manu wrote:
> On 9 April 2013 20:50, Timon Gehr <timon.gehr@gmx.ch
> <mailto:timon.gehr@gmx.ch>> wrote:
>
>     On 04/09/2013 12:28 PM, Manu wrote:
>
>         ...
>
>
>         There's nothing 'pure' about a function that has side effects.
>
>
>     If it has the same side effects every time it is called with the
>     same arguments, then there is something pure about it.
>
>
> But it doesn't. It could do anything when called a second time, same
> arguments or not.

Well, no. That's the point.

Feel free to provide an example where you think this property is violated.

(However, note that the concept of the 'same arguments', and the 'same side effects' is informal and would need a little clarification.)

> The only thing it can't do is escape a variable. That sounds more like
> 'scope' to me than 'pure'.

That is not the only thing it can't do.

On 04/09/2013 01:47 PM, Simen Kjærås wrote:
> On Tue, 09 Apr 2013 13:10:16 +0200, Artur Skawina <art.08.09@gmail.com>
> wrote:
>
>> A function that both directly depends on global mutable state (and
>> modifies it) can hardly be called pure. Can you (anybody) give a
>> D "pure" definition that allows for the program that I've posted
>> and still makes "pure" useful?
>
> Functions that are pure may only mutate mutable state explicitly passed
> to them, or created within.
>
> There. That's basically all there is to D's pure. From this definition
> arise some useful properties, e.g. that a function whose parameters are
> all immutable or implicitly castable to immutable, is referentially
> transparent.
>

pure notReferentiallyTransparent(){ // forall vacuously true
    return new Object();
}

On Tuesday, 9 April 2013 at 11:26:38 UTC, Manu wrote:
> But it doesn't. It could do anything when called a second time, same
> arguments or not.

Can it?

David

On 9 April 2013 21:30, tn <no@email.com> wrote:

> On Tuesday, 9 April 2013 at 08:33:53 UTC, Manu wrote:
>
>> On 9 April 2013 18:04, Dicebot <m.strashun@gmail.com> wrote:
>>
>>  On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
>>>
>>>  Are you saying the example above is not actually valid code?
>>>>
>>>> struct Foo {
>>>>     int a = 0;
>>>>     pure int bar( int n ) { // Weakly pure
>>>>         a += n;
>>>>         return a;
>>>>     }
>>>> }
>>>>
>>>> That's not pure. Call it twice with the same args, you'll different
>>>> answers. How can that possibly be considered pure in any sense?
>>>> And it's useless in terms of optimisation, so why bother at all? What
>>>> does
>>>> it offer?
>>>>
>>>>
>>> It is valid code. It is "weak pure". "pure' keyword means both "strong pure" or "weak pure" depending on function body. Crap.
>>>
>>>
>> How can 'weak pure' reasonably be called any kind of 'pure'? It's not pure at all. The function returns a completely different result when called twice.
>>
>
> The returned results are different because the parameters you are calling it with are different. Note that for member functions 'this' is also passed implicitly as a ref parameter. On the second call it has different value than on the first call. If you don't want to allow mutating 'this' you should make the function const, thus making the implicit 'this' parameter const ref.
>

Ah, yes. Good point. I don't know how I missed that point prior! Okay sir, I buy your argument! :)