On Tuesday, 9 April 2013 at 03:36:28 UTC, Walter Bright wrote:
> On 4/8/2013 5:39 AM, Manu wrote:
>> But D makes no further guarantee. I don't see how const in D is any different
>> than const in C++ in that sense? That's basically the concept of const, it's not
>> a useful concept for optimisation, only immutable is.
>
> In C++, it is legal to cast away const and mutate it. That is undefined behavior in D.
>
> A D compiler can assume, for example, that a const reference passed to a pure function will not mutate that reference, nor anything transitively referred to by that reference. No such assumption can be made like that in C++.

No, D have holes in its type system and so can't ensure anything. It has been show many many many times, especially by Timon and myself, and I'm kind of fed up to have to repeat that again and again, especiallt since fix proposal have recieved no attention at all.

Stop claiming that such possibility exists, or take a serious look at how to really ensure it.

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.

> It's a totally different concept,

The concept of mutation can be expressed easily in a language not directly supporting side effects. Just pass around the store explicitly.

The term you want to describe is presumably referential transparency.

> and should be named appropriately.

I guess nobody will disagree with this.

2013/4/9 Timon Gehr <timon.gehr@gmx.ch>

> On 04/09/2013 12:13 PM, Artur Skawina wrote:
>
[snip]

>
>> That's not pure by any definition,
>>
>
> I'd counter that it is pure by the D definition.
>

I completely agree with Timon. It's the definition in D.
The meaning of 'pure' keyword in D *contains* widely used "pure" meaning,
rather than differ. The usefulness of the three purity (weak-const-strong)
is still there, and the keyword choice for the concept is enough reasonable.

Kenji Hara

On 04/09/2013 12:28 PM, Manu wrote:
> There's nothing 'pure' about a function that has side effects. It's a totally different concept, and should be named appropriately.

But a natural way to define a pseudo-random number generator is a combination of a state variable together with a pure function that takes the current state variable and returns the next in the sequence -- see e.g.: http://www.cs.berkeley.edu/~mhoemmen/cs194/Tutorials/prng.pdf

(Hope I'm not being condescending here, as I imagine you know the theory of this
better than I do.)

So, I'm not sure I see the disadvantage of allowing a slight relaxation in purity that allows one to combine the state variable and transition function together in a single struct -- which is pretty much analogous to what's happening in the given examples where a private variable is being incremented by a 'pure' function.

I do agree that it's a great pity there is not a way to declare strong purity for D functions.

"deadalnix" <deadalnix@gmail.com> wrote in message news:yhvwbephdechjxvrkyal@forum.dlang.org...
>
> No, D have holes in its type system and so can't ensure anything. It has been show many many many times, especially by Timon and myself, and I'm kind of fed up to have to repeat that again and again, especiallt since fix proposal have recieved no attention at all.
>
> Stop claiming that such possibility exists, or take a serious look at how to really ensure it.

The const/pure etc systems are based on certain guarantees, and places where they can be broken are bugs.  These bugs DO NOT change what optimization opportunities are allowed by the original guarantees.  Stop claiming they do.

On Tuesday, 9 April 2013 at 10:57:20 UTC, Daniel Murphy wrote:
> "deadalnix" <deadalnix@gmail.com> wrote in message
> news:yhvwbephdechjxvrkyal@forum.dlang.org...
>>
>> No, D have holes in its type system and so can't ensure anything. It has been show many many many times, especially by Timon and myself, and I'm kind of fed up to have to repeat that again and again, especiallt since fix proposal have recieved no attention at all.
>>
>> Stop claiming that such possibility exists, or take a serious look at how to really ensure it.
>
> The const/pure etc systems are based on certain guarantees, and places where
> they can be broken are bugs.  These bugs DO NOT change what optimization
> opportunities are allowed by the original guarantees.  Stop claiming they
> do.

Right now it isn't bugs as it is how thing are defined. And will be as long as no DIP solving this issue is accepted (at which point it will become a bug).

On 04/09/13 12:51, kenji hara wrote:
> 2013/4/9 Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>>
> 
>     On 04/09/2013 12:13 PM, Artur Skawina wrote:
> 
> [snip]
> 
> 
>         That's not pure by any definition,
> 
> 
>     I'd counter that it is pure by the D definition.
> 
> 
> I completely agree with Timon. It's the definition in D.

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?

artur

On 04/09/2013 12:57 PM, Daniel Murphy wrote:
> "deadalnix" <deadalnix@gmail.com> wrote in message
> news:yhvwbephdechjxvrkyal@forum.dlang.org...
>>
>> No, D have holes in its type system and so can't ensure anything. It has
>> been show many many many times, especially by Timon and myself, and I'm
>> kind of fed up to have to repeat that again and again, especiallt since
>> fix proposal have recieved no attention at all.
>>
>> Stop claiming that such possibility exists, or take a serious look at how
>> to really ensure it.
>
> The const/pure etc systems are based on certain guarantees, and places where
> they can be broken are bugs. These bugs DO NOT change what optimization
> opportunities are allowed by the original guarantees.  Stop claiming they
> do.
>

That is certainly true, but mostly so because basically the only thing
that appears to be documented in the case of const are the guarantees
themselves.

In this case, it is pretty clear that a type system that actually
ensures that the guarantees in the spec hold could be created, but I
guess deadalnix dislikes the general scheme of:

A: I have developed an algorithm that solves 3-SAT in linear time.
B: It does not work.
A: Please report this to the bug tracker.
A: I have developed an algorithm that solves 3-SAT in linear time.

On 9 April 2013 20:50, Timon Gehr <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.
The only thing it can't do is escape a variable. That sounds more like
'scope' to me than 'pure'.

On 9 April 2013 20:57, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "deadalnix" <deadalnix@gmail.com> wrote in message news:yhvwbephdechjxvrkyal@forum.dlang.org...
> >
> > No, D have holes in its type system and so can't ensure anything. It has been show many many many times, especially by Timon and myself, and I'm kind of fed up to have to repeat that again and again, especiallt since fix proposal have recieved no attention at all.
> >
> > Stop claiming that such possibility exists, or take a serious look at how to really ensure it.
>
> The const/pure etc systems are based on certain guarantees, and places
> where
> they can be broken are bugs.  These bugs DO NOT change what optimization
> opportunities are allowed by the original guarantees.  Stop claiming they
> do.
>

The only optimisation possibility is for strong pure functions that are also nothrow, right? Was that the conditions for pure function refactoring?