pure or not pure?

[Steven Schveighoffer]

"Janice Caron" wrote
> On 10/04/2008, Steven Schveighoffer wrote:
>> Of course, but it is like a building block.  If I have a function that is
>>  pure, and that function calls nothing but other pure functions AND 
>> 'new',
>>  then why can't it also be proven to be pure?
>
> It's not the calling of new that's a problem, it's the returning of
> mutable data.
>
> If we allow "pureish" functions, then maybe a "pureish" function could
> return mutable data, but not a truly (a pure) function.
>
> The reason is that the compiler is allowed to cache the result (the
> return value from any pure function), and to re-use that result,
> instead of calling the function, whenever the input compares equal
> with last time. If any of that data is mutable, it all goes haywire.

I look at it differently.

To me, a pure function is a function that has no side effects and has 
promised to return the same thing every time it is called.  Allocating 
memory is the only function that is considered pure, but alters global state 
(i.e. the heap), and so we assume it's pure.  A function can still allocate 
data and be considered pure.

A function whose result can be memoized is to me a function that is pure, 
and also one that returns either stack or invariant data.  So a function has 
to be pure to be memoized, but not all pure functions can be memoized.

If you separate out the memoization optimization, then it's possible to have 
both worlds, without any extra keywords or terminology.  We are breaking new 
ground here, so this is the time to explore options that are not part of the 
precedent.

You might not get the compiler optimizations with a pure function that 
returns mutable heap data that you would with one that returns invariant 
heap data, but sometimes that is desirable.  The compiler cannot know all 
things about all optimizations that have been or ever will be.  At some 
point, it has to be nudged in the right direction.

> Seems to me that what's really needed here is a macro, because a macro
> is basically just a function that's always inlined, so the function
> body will be parsed /inside/ the pure specifier. Maybe macros could
> solve that problem completely.

Maybe, but this results in code bloat :)  There are always tradeoffs, it's a 
question of what is important to you.  I used to work with a device that had 
256 bytes of RAM and 8K of code space.  When working on that device, I 
learned how important it was to split common functionality into functions.

-Steve