Memory allocation purity

[Andrei Alexandrescu via Digitalmars-d]

On 5/15/14, 9:03 AM, Timon Gehr wrote:
> On 05/15/2014 05:24 PM, Andrei Alexandrescu wrote:
>> On 5/15/14, 3:31 AM, luka8088 wrote:
>>> Yeah, I read all about weak/string purity and I do understand the
>>> background. I was talking about strong purity, maybe I should pointed
>>> that out.
>>>
>>> So, to correct myself: As I understood strong purity implies
>>> memoization. Am I correct?
>>
>> Yes, as long as you don't rely on distinguishing objects by address.
>>
>> Purity of allocation is frequently assumed by functional languages
>
> Examples?

cons 1 2 is equal to cons 1 2

>> because without it it would be difficult to get much work done.
>
> Why?

It's rather obvious. You've got to have the ability to create new values 
in a pure functional programming language.

>> Then,
>> most functional languages make it difficult or impossible to distinguish
>> values by their address.
>
> If it's not impossible because of lack of the concept it's not a pure
> functional language.

Agreed.

>> In D that's easy. A D programmer needs to be
>> aware of that, and I think that's fine.
>>
>>
>> Andrei
>>
>>
>
> It's not fine: The spec claims that this problem does not exist.

We must fix the spec. Please submit a pull request, thanks.


Andrei