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+dl...@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@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.
