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.