On 2013-04-09, 17:11, Dicebot wrote:

> On Tuesday, 9 April 2013 at 14:50:58 UTC, Simen Kjærås wrote:
>> On Tue, 09 Apr 2013 16:15:40 +0200, Dicebot <m.strashun@gmail.com> wrote:
>>
>>> On Tuesday, 9 April 2013 at 14:06:31 UTC, Pelle Månsson wrote:
>>>> shouldn't be strongly pure (as it can access mutable non local state).
>>>
>>> I was under impression that pure is about verifying what function actually does, not what it probably can.
>>
>> It's based purely on function signature, so we're dealing with possibles
>> in many cases.
>
> You got me lost here again. Definition of pure in dlang.org says: "To that end, a pure function:
>
> * does not read or write any global or static mutable state
> * cannot call functions that are not pure
> * can override an impure function, but an impure function cannot override a pure one
> * is covariant with an impure function
> * cannot perform I/O"
>
> It is all about behavior, not function signature. And function that takes ref parameter and does not read/write it is pure by this list.

Indeed. The definition should be updated then, because it's the signature
that counts. Consider:

int[] foo(int* p) pure;

Given only this prototype, we can know that the function is weakly pure.
If a function body was required, we would know nothing more, are we to
assume it is strongly pure because no mutation is evident?

Of course we are not. In the same way, because D supports 'header' files
(files with implementation stripped out), the function signature must
convey all the necessary information to say if a function is strongly
pure or not.

-- 
Simen

On 4/9/13 11:42 AM, Dicebot wrote:
> On Tuesday, 9 April 2013 at 15:20:48 UTC, Andrei Alexandrescu wrote:
>>> Not gonna argue latter but former is just wrong.
>>>
>>> struct Test
>>> {
>>> int a;
>>> pure int foo1() // strong pure
>>> {
>>> return 42;
>>> }
>>>
>>> pure int foo2() // weak pure
>>> {
>>> return a++;
>>> }
>>> }
>>>
>>> Signature is the same for both functions.
>>
>> Both are weakly pure.
>>
>> Andrei
>
> And that is even more surprising as foo2 perfectly matches concept of
> pure and can be applied all possible optimizations to. It is weird.

I disagree about it being weird.

> "weak pure" is useful only to implement "strong pure". "strong pure" is
> useful only if it can be statically enforced to provide some guarantees.
> "strong pure" is useless because it shares same annotation with "weak
> pure".

I think it's a great design, very useful and innovative.


Andrei

On 04/09/2013 10:21 AM, Zach the Mystic wrote:
> deadalnix answered but too briefly it seems. I think the reason it's pure is because a struct's member functions are actually a kind of syntax sugar.

Stepping outside from any controversy for now, I think I should say that these kind of in-depth discussions and explanations of the subtleties of language features (and programming theory in general) are one of the reasons I really, really enjoy being part of the D community. :-)

On 10 April 2013 00:07, kenji hara <k.hara.pg@gmail.com> wrote:

> 2013/4/9 Dicebot <m.strashun@gmail.com>
>
>> On Tuesday, 9 April 2013 at 12:56:04 UTC, Andrei Alexandrescu wrote:
>>
>>> It is valid code. It is "weak pure". "pure' keyword means both
>>>> "strong pure" or "weak pure" depending on function body. Crap.
>>>>
>>>
>>> s/body/signature/
>>> s/Crap/Awesome/
>>>
>>
>> Not gonna argue latter but former is just wrong.
>>
>> struct Test
>> {
>>     int a;
>>     pure int foo1() // strong pure
>>     {
>>         return 42;
>>     }
>>
>>     pure int foo2() // weak pure
>>     {
>>         return a++;
>>     }
>> }
>>
>> Signature is the same for both functions.
>>
>
> Both have weak pure. Purity is always calculated only from the function
> signature.
> If you make member function "strong pure", _at least_ it should be
> qualified with "immutable".
>
>     pure int foo3() immutable // strong pure
>     {
>         return 10;
>     }
>
> Kenji Hara
>

What is an immutable function? Why is const not sufficient?

On 2013-04-09, 18:46, Manu wrote:

> What is an immutable function? Why is const not sufficient?

Immutable requires that the struct/class be immutable, const
may be called on mutable instances. Thus, the object may be
changed in a different thread while the const function executes.
Not so with immutable.

-- 
Simen

On Tuesday, 9 April 2013 at 16:15:38 UTC, Andrei Alexandrescu wrote:
>> "weak pure" is useful only to implement "strong pure". "strong pure" is
>> useful only if it can be statically enforced to provide some guarantees.
>> "strong pure" is useless because it shares same annotation with "weak
>> pure".
>
> I think it's a great design, very useful and innovative.

Agree on it being great and innovative. But I fail to see usefulness with current design. Can you provide examples how current pure design allows for better code / optimizations?

On 04/09/13 15:22, Timon Gehr wrote:
> On 04/09/2013 03:18 PM, Artur Skawina wrote:
>> On 04/09/13 13:47, 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.
>>
>>     struct S;
>>     int f(S* p) pure;
>>     S* n();
>>
>>     int g = 0;
>>
>>     int main() {
>>        S* s = n();
>>        f(s);
>>        return g;
>>     }
>>
>> Is main() guaranteed to return '0'?
> 
> No. What is the point?

I'm exploring the D purity definition given above, which is either incorrect or extremely misleading. My example was bad though, as it had too many unstated assumptions. A better one would have been:

   struct S;
   int g;
   int f(S* p) pure;
   int h(S* s) { g = 0; f(s); return g; }
   // Is 'h' guaranteed to return '0'?

Obviously, the answer is no.
Yet this will be expected by anyone not aware of how "pure" works in D.
Adding "const" would only change the R/W dep to a R/O one (IOW 'f' could
still return different values depending on 'g').

artur

On Tuesday, 9 April 2013 at 16:55:07 UTC, Simen Kjaeraas wrote:
> On 2013-04-09, 18:46, Manu wrote:
>
>> What is an immutable function? Why is const not sufficient?
>
> Immutable requires that the struct/class be immutable, const
> may be called on mutable instances. Thus, the object may be
> changed in a different thread while the const function executes.
> Not so with immutable.

Not in other thread (as it would require to be shared or is undefined behavior) but vie delegate for instance.

On Tuesday, 9 April 2013 at 17:39:47 UTC, Dicebot wrote:
> On Tuesday, 9 April 2013 at 16:15:38 UTC, Andrei Alexandrescu wrote:
>>> "weak pure" is useful only to implement "strong pure". "strong pure" is
>>> useful only if it can be statically enforced to provide some guarantees.
>>> "strong pure" is useless because it shares same annotation with "weak
>>> pure".
>>
>> I think it's a great design, very useful and innovative.
>
> Agree on it being great and innovative. But I fail to see usefulness with current design. Can you provide examples how current pure design allows for better code / optimizations?

Strongly pure functions can call weakly pure function while keeping its properties.

So it loosen the constraint on strongly pure function while keeping the benefit.

On Tuesday, 9 April 2013 at 16:41:08 UTC, Joseph Rushton Wakeling wrote:
> On 04/09/2013 10:21 AM, Zach the Mystic wrote:
>> deadalnix answered but too briefly it seems. I think the reason it's pure is
>> because a struct's member functions are actually a kind of syntax sugar.
>
> Stepping outside from any controversy for now, I think I should say that these
> kind of in-depth discussions and explanations of the subtleties of language
> features (and programming theory in general) are one of the reasons I really,
> really enjoy being part of the D community. :-)

Thanks, man! The truth is, compared to some of the heavyweights here, I'm very new to programming. That being said, I DO endeavor to really understand what's going on with the inner workings. I don't want anything to be mysterious which doesn't have to be!