Memory allocation purity

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu May 15 02:35:19 PDT 2014


On Thu, 15 May 2014 10:14:48 +0200
luka8088 via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
> > On Thu, 15 May 2014 05:51:14 +0000
> > via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> >
> >> Yep, purity implies memoing.
> >
> > No, it doesn't. _All_ that it means when a function is pure is that
> > it cannot access global or static variables unless they can't be
> > changed after being initialized (e.g. they're immutable, or they're
> > const value types), and it can't call any other functions which
> > aren't pure. It means _nothing_ else. And it _definitely_ has
> > nothing to do with functional purity.
> >
> > Now, combined with other information, you _can_ get functional
> > purity out it - e.g. if all the parameters to a function are
> > immutable, then it _is_ functionally pure, and optimizations
> > requiring functional purity can be done with that function. But by
> > itself, pure means nothing of the sort.
> >
> > So, no, purity does _not_ imply memoization.
> >
> > - Jonathan M Davis
> >
>
> Um. Yes it does. http://dlang.org/function.html#pure-functions
> "functional purity (i.e. the guarantee that the function will always
> return the same result for the same arguments)"
>
> The fact that it should not be able to effect or be effected by the
> global state is not a basis for purity, but rather a consequence.
>
> Even other sources are consistent on this matter, and this is what
> purity by definition is.
>

The reread the paragraph at the top of the section of the documentation
that you linked to:

"Pure functions are functions which cannot access global or static,
mutable state save through their arguments. This can enable
optimizations based on the fact that a pure function is guaranteed to
mutate nothing which isn't passed to it, and in cases where the
compiler can guarantee that a pure function cannot alter its arguments,
it can enable full, functional purity (i.e. the guarantee that the
function will always return the same result for the same arguments)."

That outright says that pure only _can_ enable functional purity - in
particular when the compiler is able to guarantee that the function
cannot mutate its arguments. pure itself however means nothing of the
sort. The fact that pure functions cannot access global state _is_ the
basis for functional purity when combined with parameters that
arguments cannot be mutated.

If you get hung up on what the concept of functional purity is or what
you thought pure was before using D, then you're going to have a hard
time understanding what pure means in D. And yes, it's a bit weird, but
it comes from the practical standpoint of how to make functional purity
possible without being too restrictive to be useful. So, it really
doesn't matter what other sources say about what purity means. That's
not what D's pure means. D's pure is just a building block for what
purity normally means. It makes it so that the compiler can detect
functional purity and then optimize based on it, but it doesn't in and
of itself have anything to do with functional purity.

If the documentation isn't getting that across, then I guess that it
isn't clear enough. But I would have thought that the part that said
"and in cases where the compiler can guarantee that a pure function
cannot alter its arguments, it can enable full, functional purity"
would have made it clear that D's pure is _not_ functionally pure by
itself. The first part of the paragraph says what pure really means:
"Pure functions are functions which cannot access global or static,
mutable state save through their arguments." Everything else with
regards to functional purity is derived from there, but in and of
itself, that's _all_ that the pure attribute in D means.

See also: http://klickverbot.at/blog/2012/05/purity-in-d/

- Jonathan M Davis


More information about the Digitalmars-d mailing list