On Thu, 15 May 2014 09:28:57 -0400, Dicebot <[email protected]> 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
<[email protected]> 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
