Idea: partially pure functions

[Steven Schveighoffer]

"Bruno Medeiros" wrote
> Steven Schveighoffer wrote:
>> "Bruno Medeiros" wrote
>>> Steven Schveighoffer wrote:
>>>> However, I tend to agree with Don.  What you want is a relaxation of 
>>>> the rules, which can easily happen after pure functions are supported. 
>>>> In fact, you don't even need any new keywords or syntax, the compiler 
>>>> just implies the partial purity from the parameter/return types.
>>>>
>>> The compiler can only infer partial purity if it has access to the 
>>> function body (just the same as it can infer normal purity). But if you 
>>> only have a function signature, you need a keyword.
>>
>> I meant an *extra* keyword.  If you mark a function as pure, it can be 
>> partially pure or fully pure depending on the arguments.  However, having 
>> an extra keyword lets the developer decide whether he is expecting a 
>> function to be partially pure or not, so there are no surprises :)  I'd 
>> vote for a new keyword, but this does not need to happen right away.
>>
>
> That decision of "whether he is expecting a function to be partially pure 
> or " pure is not a useful decision to have to make, it's redundant (and 
> thus cumbersome) to ask the programmer to specify that.

It's not possible to call a partially pure function with mutable arguments 
from a non-pure function.  Doing so would be a nightmare for the compiler. 
So from a maintainability perspective, changing a function from fully pure 
to partially pure changes the contract that the function provides.

However, changing from fully pure to partially pure involves changing an 
argument type, so in essence, code that used the fully pure function would 
break anyways...  Having an extra keyword for 'partially pure' is probably 
not necessary, so I agree with you now.

>
> Also, having two different keywords would impossibilitate or difficult 
> templating of constness (like with the "scoped const" proposal).
>
> Just think of 'pure' as meaning: this function does not depend on, or 
> modify, external state. (external state being any data other than the 
> parameters)

For D, there is also the notion that a pure function will not be affected by 
it's parameters changing mid-way through the function.

>>>> As for your idea, to be complete, I'd say there are different levels of 
>>>> partially pure functions.
>>>>
>>>> level 1: mutable return value, but const/invariant parameters.  These 
>>>> functions can be re-ordered, and can be called from pure or unpure 
>>>> functions.  The result cannot be memoized.
>>> This is already a regular pure function. The idea that a pure function 
>>> has to return an invariant is a misconception, it can safely return 
>>> mutable data. It can me memoized just the same (although a copy would 
>>> have to be made if the result is not invariant)
>>
>> I would hope that the compiler would not memoize if I returned a mutable 
>> piece of data, as I would generally expect to use this function as a way 
>> to initialize some data that I want to build with (in a pure function or 
>> otherwise).  If I wanted it to memoize, I can return invariant.  For 
>> example, to memoize on 'new' would be a waste, but 'new' can be 
>> considered a pure (arguably partially pure) function.  Sometimes 
>> memoization is not desirable, especially if you are rarely calling the 
>> pure function with the same arguments.
>>
>
> I said the compiler *could* memoize the result just the same. Doesn't mean 
> it *should* memoize if the result is mutable.
> As a matter of fact, even if the result is invariant, doesn't mean the 
> compiler should memoize it. Memoization is a complicated optimization that 
> likely only the user knows when it should be applied, not the compiler.

I suspect the goal of Walter is to not have the developer make the decision 
to memoize...  Similar to how we do not have the ability to force inlining, 
but we have the ability to force NOT inlining (by making a function opaque). 
I believe making a pure function return mutable heap data should be a signal 
that the compiler does not memoize the result.

>> I guess it all depends on what you consider partially pure :)  I believe 
>> the current rules as stated on D's website require invariant return data, 
>> or data that can be implicitly cast to invariant.
>
> In Andrei's latest presentation 
> (http://www.digitalmars.com/d/2.0/accu-functional.pdf)
> when he lists the requirements for pure, it does not say that is should 
> return invariant data. (and I'm assuming those requirements are complete)

Those requirements are not complete.  For instance, the web site says that 
pure functions can call new expressions, but that is not stated in the pdf 
(or at least, I don't remember seeing it).  I think it will eventually be 
stated that pure functions initially will have to return invariant data, or 
data that can be implicitly cast to invariant.  Unless I can convince Andrei 
otherwise :)

-Steve