Proposal: Relax rules for 'pure'

Don nospam at nospam.com
Wed Sep 22 08:53:22 PDT 2010


Robert Jacques wrote:
> On Wed, 22 Sep 2010 04:13:34 -0400, Don <nospam at nospam.com> wrote:
> 
>> Don wrote:
>>> The docs currently state that:
>>
>>> PROPOSAL:
>>> Drop the first requirement. Only one requirement is necessary:
>>>  A pure function does not read or write any global mutable state.
>>>
>>
>> Wow. It seems that not one person who has responded so far has 
>> understood this proposal! I'll try again. Under this proposal:
> 
> Funny, your re-iteration appears to coincided to my previous 
> understanding. So either I've mis-understood twice, or I didn't 
> sufficiently demonstrate my understanding when I made my critique. :) 
> That said, I do think this version is much clearer and understandable.
> 
>> If you see a function which has mutable parameters, but is marked as 
>> 'pure', you can only conclude that it doesn't use global variables. 
>> That's not much use on it's own. Let's call this a 'weakly-pure' 
>> function.
>>
>> However, if you see a function maked as 'pure', which also has only 
>> immutable parameters, you have the same guarantee which 'pure' gives 
>> us as the moment. Let's call this a 'strongly-pure' function.
>>
>> The benefit of the relaxed rule is that a strongly-pure function can 
>> call a weakly-pure functions, while remaining strongly-pure.
>> This allows very many more functions to become strongly pure.
>>
>> The point of the proposal is *not* to provide the weak guarantee. It 
>> is to provide the strong guarantee in more situations.
> 
> The problem from my point of view is that the programmer can not declare 
> that a function should be 'strongly-pure' or 'weakly-pure'.

Yes they can. They just need to declare the parameters to be immutable.

  Essentially,
> the point of the proposal is *to* provide the weak guarantee and leave 
> the strong guarantee up to a sufficiently smart compiler. 

No it is not.
The key point you're not getting is that the difference between strong 
and weak purity can be determined from the function signature alone. You 
can do it in a very simple piece of library code.
The compiler doesn't need to be involved at all. It's utterly trivial.

Establishing weak purity, OTOH, is very complicated, and requires the 
compiler _and the linker_.

And I really
> don't want a function to suddenly run 8x slower, just because Joe-coder 
> changed a type somewhere and made my 'strongly-pure' inner-loop 
> 'weakly-pure'. That said, if we can only have one type of purity in the 
> language, I think 'weakly-pure' is more powerful a concept than 
> 'strongly-pure'.


More information about the Digitalmars-d mailing list