pure or not pure?

[Steven Schveighoffer]

"Janice Caron" wrote
> On 10/04/2008, Steven Schveighoffer wrote:
>>  Then I should be able to do
>>
>>  h(x)
>>  {
>>     statement1;
>>     statement2;
>>  }
>>
>>  f(x)
>>  {
>>    h(x);
>>  }
>>
>>  g(x)
>>  {
>>    h(x);
>>  }
>
> What you're asking for is what someone else called "amoral" (slightly
> pure). You're suggesting that h be pure-/ish/. It doesn't have to be
> completely pure per se, but it must be pure /enough/ such that when
> embedded within f or g, f and g remain pure.
>
> I have no idea whether or not D will be able to accomodate this
> concept. Strictly functional programming doesn't have it. D might or
> might not. If we do, I suspect it will require another keyword.

We may be able to do it without a keyword.  For example, if a pure function 
returns an invariant(char)[], it means that the return value can be 
memoized, if not, it means that the return value is well-defined, but 
another call to the function will return another copy of the same data. 
Reordering is OK, because it always returns the same data.  You could even 
wrap this in another version that returns invariant data, which then allows 
for memoization, if you know you're going to call it a lot, and don't care 
about mutating the data afterwards.

>>  char[] c = new char[5];
>>
>> is invalid inside a pure function because the compiler cannot verify
>>  uniqueness of mutable heap data, right?
>
> No. As I said, new is special. It's integral to the language.

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?

-Steve