On Wed, 22 Sep 2010 04:13:34 -0400, Don <nos...@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'. Essentially,
the point of the proposal is *to* provide the weak guarantee and leave the
strong guarantee up to a sufficiently smart compiler. 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'.
