Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Thu, 15 May 2014 11:42:00 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 05/15/2014 02:57 PM, Steven Schveighoffer wrote:
>> On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad
>> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>>
>>> On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
>>>> A little example of D purity (this compiles):
>>>
>>>> bool randomBit() pure nothrow @safe {
>>>>     return (new int[1].ptr) > (new int[1].ptr);
>>>> }
>>>
>>> Yes, and then you may as well allow a random generator with private
>>> globals. Because memoing is no longer sound anyway.
>>
>> This has nothing to do with allocators being pure. They must be pure as
>> a matter of practicality.
>>
>> The issue that allows the above anomaly is using the address of
>> something. There is a reason functional languages do not allow these
>> types of things. But in functional languages, allocating is allowed.
>> ...
>
> Not really, allocation is just an implementation detail. The  
> computational language is meaningful independent of how you might  
> achieve evaluation of expressions. I can in principle evaluate an  
> expression of such a language on paper without managing a separate  
> store, even though this usually will help efficiency.
>
> Functional programming languages are not about taking away features from  
> a procedural core language. They are based on the idea that the  
> fundamental operation is substitution of terms.

But they do not deal in explicit pointers. Otherwise, that's a can of  
worms that would weaken the guarantees, similar to how D's guarantees are  
weakened.

We have no choice in D, we must accept that explicit pointers are used.

>> To be honest, code that would exploit such an anomaly is only ever used
>> in "proof" exercises, and never in real code.
>
> Hashtables are quite real.

Pretend I'm ignorant, what does this imply?

> This is the issue:
>
> On Thu, 15 May 2014 10:48:07 +0000
> Don via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>
>>> Yes. 'strong pure' means pure in the way that the functional
>>> language crowd means 'pure'.
>>> 'weak pure' just means doesn't use globals.
>
> There is no way to make that claim precise in an adequate way such that  
> it is correct.

This doesn't help, I'm lost with this statement.

-Steve