pure or not pure?

Steven Schveighoffer schveiguy at yahoo.com
Thu Apr 10 06:08:29 PDT 2008


"Georg Wrede" wrote
> Steven Schveighoffer wrote:
>> "Janice Caron" wrote
>>
>> So how is new char[] a pure function?  And why can't I 'wrap' new?  For 
>> instance, if I have a function:
>>
>> int[] createIncreasingSequence(int s, int e, int step){...}
>>
>> which creates an array of ints that start at s and end at e, increasing 
>> by step each time, why can't I make that pure?  i.e. I want to specify my 
>> own way to initialize an array.  If I do that in 10 different pure 
>> functions, you're saying I have to re-implement that code in each one?
>
> The return value must be immutable if you're going to use it several 
> times.

Agreed.  But I don't want to use it several times, I want to use it once :)

I want it to act like new does.  For example, if I have

char[] c = new char[5];

in two different pure functions, new better not return the same exact memory 
space for both!  It should be called every time.  But I can't do this with a 
custom function because pure functions can only call other pure functions. 
Basically, I'm asking if there will be a way to move a common piece of a 
function that allocates and initializes data out of a pure function and into 
another.

It would be cool if the compiler did not perform special optimizations (such 
as memoization) on pure functions that return mutable heap data, but still 
enforced the rules of purity.

> And if you want to cache the return values outside of the function (as in 
> only returning a new array when new parameters are used, and otherwise 
> just a reference to a previously returned one), then I guess I don't have 
> an opinion. :-?
>
>> This was misleading on my part.  I should have asked instead of these two 
>> questions, if substr is allowed to be pure, can it be called from a 
>> non-pure function?  In the context of being called from a pure function, 
>> src is unique, because pure has to have unique data.  But in the context 
>> of calling from a non-pure function, it might not be...
>
> Ultimately, any function is called from main(). Which is a non-pure 
> function.

This is a special case of pure function.  Let's say I have a pure function:

pure invariant(char)[] f()
{
    char[] c = new char[15];
    g(c);
    return assumeUnique!(c);
}

Now, if g is a pure function that takes a char[] argument and accesses the 
data referenced by the argument, it could be OK to call it from another pure 
function because we could assume that the pure function can only use heap 
data that is 'local' to the function.  But it might be invalid to call such 
a pure function from a non-pure function because data held by a non-pure 
function is not always considered 'local'.  On the other hand, if a pure 
function can hold pointers to heap data that is shared, but just can't use 
it, then a pure function that takes mutable heap data might not be able to 
use it, so a function like g() isn't possible.

If pure functions only allow invariant heap parameters and invariant heap 
returns, then this whole discussion becomes moot, but if they accept 
non-invariant heap parameters, or allow non-invariant heap returns, I want 
to know what the rules for those are.  It seems to me that only allowing 
invariant heap data is a severe limitation that will leave D functional 
programming crippled in the face of an actual FP language.

-Steve 





More information about the Digitalmars-d mailing list