Memory allocation purity

[Timon Gehr via Digitalmars-d]

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.

> 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.

> I don't think it's an issue.
>
> -Steve

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.