Branch: refs/heads/master
  Home:   https://github.com/D-Programming-Language/phobos

  Commit: 4f28db6ffb63f85e2aa22892c4cdaa69129a3dc9
      https://github.com/D-Programming-Language/phobos/commit/4f28db6ffb63f85e2aa22892c4cdaa69129a3dc9
  Author: Walter Bright <walter at walterbright.com>
  Date:   2011-06-25 (Sat, 25 Jun 2011)

  Changed paths:
    M std/bigint.d
  M std/complex.d
  M std/datetime.d
  M std/internal/math/biguintcore.d
  M std/parallelism.d

  Log Message:
  -----------
  not really pure

On 2011-06-25 19:57, noreply at github.com wrote:
>   Branch: refs/heads/master
>   Home:   https://github.com/D-Programming-Language/phobos
> 
>   Commit: 4f28db6ffb63f85e2aa22892c4cdaa69129a3dc9
> 
> https://github.com/D-Programming-Language/phobos/commit/4f28db6ffb63f85e2a
> a22892c4cdaa69129a3dc9 Author: Walter Bright <walter at walterbright.com>
>   Date:   2011-06-25 (Sat, 25 Jun 2011)
> 
>   Changed paths:
>     M std/bigint.d
>   M std/complex.d
>   M std/datetime.d
>   M std/internal/math/biguintcore.d
>   M std/parallelism.d
> 
>   Log Message:
>   -----------
>   not really pure

If they're not really pure, they shouldn't compile with pure. Also, not being able to use opAssign in pure functions could be rather annoying. Why doesn't that work?

- Jonathan M Davis

On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>
> If they're not really pure, they shouldn't compile with pure.

They won't in the upcoming checkin.

>   Also, not being
> able to use opAssign in pure functions could be rather annoying. Why doesn't
> that work?
>

Pure functions cannot mutate data through pointers passed to them.

On 2011-06-25 20:23, Walter Bright wrote:
> On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
> > If they're not really pure, they shouldn't compile with pure.
> 
> They won't in the upcoming checkin.
> 
> >   Also, not being
> > 
> > able to use opAssign in pure functions could be rather annoying. Why doesn't that work?
> 
> Pure functions cannot mutate data through pointers passed to them.

Weakly pure functions are supposed to be able to.

- Jonathan M Davis

On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
> On 2011-06-25 20:23, Walter Bright wrote:
>> On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>> If they're not really pure, they shouldn't compile with pure.
>> They won't in the upcoming checkin.
>>
>>>    Also, not being
>>>
>>> able to use opAssign in pure functions could be rather annoying. Why doesn't that work?
>> Pure functions cannot mutate data through pointers passed to them.
> Weakly pure functions are supposed to be able to.
>
>

The compiler wasn't checking this at all. It's possible we can loosen things up after we understand the issues better, but we should start with being very conservative about what purity means.

On 2011-06-25 20:31, Walter Bright wrote:
> On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
> > On 2011-06-25 20:23, Walter Bright wrote:
> >> On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
> >>> If they're not really pure, they shouldn't compile with pure.
> >> 
> >> They won't in the upcoming checkin.
> >> 
> >>>    Also, not being
> >>> 
> >>> able to use opAssign in pure functions could be rather annoying. Why doesn't that work?
> >> 
> >> Pure functions cannot mutate data through pointers passed to them.
> > 
> > Weakly pure functions are supposed to be able to.
> 
> The compiler wasn't checking this at all. It's possible we can loosen things up after we understand the issues better, but we should start with being very conservative about what purity means.

It's fine with me if we make pure more restrictive as we sort it all out, but ultimately, if we can't make member functions at least weakly pure (as it appears is now the case - or at least non-const member functions can't pure; I'm not sure which it is without looking a lot closer at the changes that you made), then that's going to be a pretty big blow to purity in general. We'll still be better off than we were prior to weakly pure being introduced, but it'll still be extremely restrictive.

- Jonathan M Davis

----- Original Message -----

> From: Walter Bright <walter at digitalmars.com>
> 
> 
> 
> On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
>>  On 2011-06-25 20:23, Walter Bright wrote:
>>>  On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>>>  If they're not really pure, they shouldn't compile with
> pure.
>>>  They won't in the upcoming checkin.
>>> 
>>>> ? ? Also, not being
>>>> 
>>>>  able to use opAssign in pure functions could be rather annoying.
> Why
>>>>  doesn't that work?
>>>  Pure functions cannot mutate data through pointers passed to them.
>>  Weakly pure functions are supposed to be able to.
>> 
>> 
> 
> The compiler wasn't checking this at all. It's possible we can loosen things up after we understand the issues better, but we should start with being very conservative about what purity means.

Don is probably the best to explain it, since he formalized the notion of weak pure,? but I wholeheartedly agree with Jonathan, member functions that access or mutate mutable members can and should be pure, as long as they don't access or mutate shared or global data.

If that isn't true, then the whole notion of weak purity that allows pure functions to be useful is out the window.? I.e. pure functions will be reserved to the likes of std.math.sin, and nobody will mark any major functions pure.

I thought weak purity had already been scrutinized, accepted, and purposefully added to the compiler?? Were you not part of that discussion (I thought you were)?? Does this reverse that decision?? If so, I think it is the wrong move.? Weak purity made pure functions not only useful, but actually pleasant to work with.

To recap weak purity, a pure function is one that does not access mutable or const data that is shared or global, and it can only call pure functions.
A Strong-pure function is a pure function whose parameters and return value are all immutable or implicitly convertible to immutable.

The compiler can only make pure-related optimizations on strong-pure functions.? However, since weak-pure functions are still pure, strong-pure functions can call them.

For instance, a useful idiom would be for a weak-pure function to sort an array in place.? Without weak-purity, one has to re-implement sorting an array in every pure function they need it for, or write a functional-style sort (not a very easy or efficient thing).

In other words, weak purity makes pure functions written in an imperative style able to be modular.? Without it, you have to resort to functional style, or mixin everything into your local scope.

-Steve

I understand and agree, but the previous code was so broken it would allow assignment through the 'this' pointer.

On 6/27/2011 3:51 AM, Steve Schveighoffer wrote:
> ----- Original Message -----
>
>> From: Walter Bright<walter at digitalmars.com>
>>
>>
>>
>> On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
>>>   On 2011-06-25 20:23, Walter Bright wrote:
>>>>   On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>>>>   If they're not really pure, they shouldn't compile with
>> pure.
>>>>   They won't in the upcoming checkin.
>>>>
>>>>>      Also, not being
>>>>>
>>>>>   able to use opAssign in pure functions could be rather annoying.
>> Why
>>>>>   doesn't that work?
>>>>   Pure functions cannot mutate data through pointers passed to them.
>>>   Weakly pure functions are supposed to be able to.
>>>
>>>
>> The compiler wasn't checking this at all. It's possible we can loosen
>> things up
>> after we understand the issues better, but we should start with being very
>> conservative about what purity means.
> Don is probably the best to explain it, since he formalized the notion of weak pure,  but I wholeheartedly agree with Jonathan, member functions that access or mutate mutable members can and should be pure, as long as they don't access or mutate shared or global data.
>
> If that isn't true, then the whole notion of weak purity that allows pure functions to be useful is out the window.  I.e. pure functions will be reserved to the likes of std.math.sin, and nobody will mark any major functions pure.
>
> I thought weak purity had already been scrutinized, accepted, and purposefully added to the compiler?  Were you not part of that discussion (I thought you were)?  Does this reverse that decision?  If so, I think it is the wrong move.  Weak purity made pure functions not only useful, but actually pleasant to work with.
>
> To recap weak purity, a pure function is one that does not access mutable or const data that is shared or global, and it can only call pure functions.
> A Strong-pure function is a pure function whose parameters and return value are all immutable or implicitly convertible to immutable.
>
> The compiler can only make pure-related optimizations on strong-pure functions.  However, since weak-pure functions are still pure, strong-pure functions can call them.
>
> For instance, a useful idiom would be for a weak-pure function to sort an array in place.  Without weak-purity, one has to re-implement sorting an array in every pure function they need it for, or write a functional-style sort (not a very easy or efficient thing).
>
> In other words, weak purity makes pure functions written in an imperative style able to be modular.  Without it, you have to resort to functional style, or mixin everything into your local scope.
>
> -Steve
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>

On 2011-06-27 11:28, Walter Bright wrote:
> I understand and agree, but the previous code was so broken it would allow assignment through the 'this' pointer.

Not being able to assign to member variables in a weakly pure function will be devastating to purity. If we can't do it, we can't do it, but it's a huge setback if we can't. Or do you mean something else by assignment through the this pointer?

- Jonathan M Davis

I looked at the changes you made to phobos.? Let me examine one of them:

struct Complex(T) if (isFloatingPoint!T)
{
????/** The real part of the number. */
????T re;

????/** The imaginary part of the number. */
????T im;


@safe nothrow /* removed attribute: pure */ // The following functions depend only on std.math. {

????/** Calculate the absolute value (or modulus) of the number. */
????@property T abs() const
????{
????????return hypot(re, im);
????}
In fact, the abs function *is* pure (since hypot is pure).? Which is why I'm confused.? It does not modify any global or shared state.

If the compiler no longer compiles this as pure, then it does *NOT* implement weak-pure semantics.? So I'm not sure what you mean by "I agree".? This is a step backwards.

I'll examine it directly.? Complex!T.abs takes one parameter, a ref Complex!T.? Given the definition of weak-pure, a function is allowed to accept and access references to mutable data -- even change them -- as long as the data is not typed as shared.? It also does not call any impure functions or access any global variables.? I think you are completely wrong in thinking this cannot be pure.? If the compiler does not accept this, then the compiler has not implemented weak-pure.

Do you have another case (even a theoretical one) that would have incorrectly compiled before this change?? Certainly the changes I looked at were not accepts-invalid cases, given the context that weak-pure was implemented.

The other option is you simply don't want weak-pure.? Which is a design decision I don't agree with, but it's your decision.? It might be hard to get those worms back in the can now!

-Steve


----- Original Message -----
> From: Walter Bright <walter at digitalmars.com>
> To: phobos at puremagic.com
> Cc:
> Sent: Monday, June 27, 2011 2:28 PM
> Subject: Re: [phobos] [D-Programming-Language/phobos] 4f28db: not really pure
> 
> I understand and agree, but the previous code was so broken it would allow assignment through the 'this' pointer.
> 
> On 6/27/2011 3:51 AM, Steve Schveighoffer wrote:
>>  ----- Original Message -----
>> 
>>>  From: Walter Bright<walter at digitalmars.com>
>>> 
>>> 
>>> 
>>>  On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
>>>> ?  On 2011-06-25 20:23, Walter Bright wrote:
>>>>> ?  On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>>>>> ?  If they're not really pure, they shouldn't
> compile with
>>>  pure.
>>>>> ?  They won't in the upcoming checkin.
>>>>> 
>>>>>> ? ? ? Also, not being
>>>>>> 
>>>>>> ?  able to use opAssign in pure functions could be rather
> annoying.
>>>  Why
>>>>>> ?  doesn't that work?
>>>>> ?  Pure functions cannot mutate data through pointers passed to
> them.
>>>> ?  Weakly pure functions are supposed to be able to.
>>>> 
>>>> 
>>>  The compiler wasn't checking this at all. It's possible we can
> loosen
>>>  things up
>>>  after we understand the issues better, but we should start with being
> very
>>>  conservative about what purity means.
>>  Don is probably the best to explain it, since he formalized the notion of
> weak pure,? but I wholeheartedly agree with Jonathan, member functions that access or mutate mutable members can and should be pure, as long as they don't access or mutate shared or global data.
>> 
>>  If that isn't true, then the whole notion of weak purity that allows
> pure functions to be useful is out the window.? I.e. pure functions will be reserved to the likes of std.math.sin, and nobody will mark any major functions pure.
>> 
>>  I thought weak purity had already been scrutinized, accepted, and
> purposefully added to the compiler?? Were you not part of that discussion (I thought you were)?? Does this reverse that decision?? If so, I think it is the wrong move.? Weak purity made pure functions not only useful, but actually pleasant to work with.
>> 
>>  To recap weak purity, a pure function is one that does not access mutable
> or const data that is shared or global, and it can only call pure functions.
>>  A Strong-pure function is a pure function whose parameters and return value
> are all immutable or implicitly convertible to immutable.
>> 
>>  The compiler can only make pure-related optimizations on strong-pure
> functions.? However, since weak-pure functions are still pure, strong-pure functions can call them.
>> 
>>  For instance, a useful idiom would be for a weak-pure function to sort an
> array in place.? Without weak-purity, one has to re-implement sorting an array in every pure function they need it for, or write a functional-style sort (not a very easy or efficient thing).
>> 
>>  In other words, weak purity makes pure functions written in an imperative
> style able to be modular.? Without it, you have to resort to functional style, or mixin everything into your local scope.
>> 
>>  -Steve
>> 
>>  _______________________________________________
>>  phobos mailing list
>>  phobos at puremagic.com
>>  http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>