[ I've added some of Damian's text back into Michael's message to save replying to two separate messages. ]
On Mon, Nov 11, 2002 at 09:44:37AM -0800, Michael Lazzaro wrote: > On Monday, November 11, 2002, at 02:19 AM, Damian Conway wrote: > > I can certainly see your point, but to me this is disquieteningly > > reminiscent of the horror that is C<const> in C++ methods. Because, Yes, there are those overtones. You can never retrofit purity. > > 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. Yes, unless "pure" really means "pure enough". > > 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. I think I agree that if you want to give perl a hint about how to optimise your program, and you want to specify that the results of calling a function should be cached, then "cached" seems the best way to do that. > > 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. :-( I would say that would be the whole point of "pure". If you declare a function to be "pure" (and you're telling the truth), then when and how often that function is called should have no bearing on the output of the program, except maybe for when it appears. The function could be cached, optimised away, farmed out to one of the 63 processors you're not using or be optimised in any number of helpful ways. Having said all that, I'm not overly wedded to the idea. It seems useful, but so does actually specifying "cached". I'm not convinced that either has to be a part of the core language to be useful. In fact, I only poked my head up because I knew the answer to Nick's question :-) > Amen. The more abstract or metaphorical the name, the more difficult > it is to be really sure of what it does. Of the choices, "cached" > seems by far the most self-explanatory. If we used "pure", we'd have > to teach people what "pure" means, which would be much harder than > teaching them what "cached" means. A "pure" function may be run zero, one or more times every time you call it. And every time you don't. ;-) [ I notice that Piers has just said about the same as me in one sentence. ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
