Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Thu, 15 May 2014 09:28:57 -0400, Dicebot <public at dicebot.lv> wrote:

> On Thursday, 15 May 2014 at 12:57:43 UTC, 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.
>
> Which is what makes D pure lint-like helper and not effective  
> optimization enabler. This part of type system was under-designed  
> initially, it should have been much more restrictive.

It's easy to say this, but the restrictions to apply would be draconian. I  
think it would be nearly impossible to prevent such abuses in a language  
with explicit references.

>> To be honest, code that would exploit such an anomaly is only ever used  
>> in "proof" exercises, and never in real code. I don't think it's an  
>> issue.
>
> This is not true. Because of such code you can't ever automatically  
> memoize strongly pure function results by compiler. A very practical  
> concern.

I think you can still memoize these cases. There is no reason for the  
language to support a pure RNG.

-Steve