Paul Johnson wrote:
Part of the reason I would prefer something like "pure" over something
like "cached" is because it describes the function rather than telling
the compiler how to deal with it. That feels better to me. It's
working at a higher level. Maybe the end result is the same, or maybe
there are other optimisations which can be made with "pure" functions.
It's a way of nailing down the contract on the function rather than
specifying implementation details.
I can certainly see your point, but to me this is disquieteningly
reminiscent of the horror that is C<const> in C++ methods. Because,
if you're serious about C<pure> meaning "pure" in the mathematical
sense, then C<pure> subs can't access globals or C<caller>,
can't have C<rw> parameters, and call non-C<pure> subroutines.
One of the reasons I like C<cached> is because it does specify
exactly the way the subroutine is to behave (i.e. be called the first time,
and not called every subsequent time the same arguments are supplied). So
I can do nasty^H^H^H^H^Hhandy things like giving the sub side-effects, in
the sure knowledge that they won't be invoked more than once.
With C<pure> I can never be sure what optimizations the compiler is
or isn't going to make, or even whether those optimzations will be the
same from platform to platform [*]. So I can never be sure what the
precise behaviour of my sub will be. :-(
Damian
[*] I can easily imagine architectures under which re-calling a particular
pure function is actually faster than retrieving a previously cached
result.
