On Sun, Jan 11, 2009 at 8:51 AM, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote: > Walter Bright wrote: >> >> Andrei Alexandrescu wrote: >>> >>> Michel Fortin wrote: >>>> >>>> On 2009-01-10 00:10:11 -0500, Andrei Alexandrescu >>>> <seewebsiteforem...@erdani.org> said: >>>> >>>>>> The problem is identifying if this would be faster than recomputing >>>>>> the return value. >>>>> >>>>> I used memoizers for exp and log (the most called functions in some >>>>> code I wrote) and it made the original version feel like it was driving in >>>>> reverse. >>>> >>>> That's only true because, in your specific context, those functions were >>>> called often with the same input. In a program that rarely use the same >>>> inputs, your memoizing functions will just waste time and memory. >>> >>> No, because I use interpolation. >> >> That's way beyond the ability of a compiler to do automatically. The >> compiler would have to understand that the pure function produces continuous >> results. > > You're replying to the wrong guy. I'm saying: the compiler shouldn't have to > do so, but it should allow functions to do it. > > Lately it looks like a lot of the problems discussed here inevitably lead to > a built-in feature. We want properties, let's have a property thingy. We > want memoization, let's have a memoize thingy. We want optimally aligned > structures, let's have an optimal align thingy. I'm holding my breath for a > request for the kitchen sink thingy.
Just get Walter to implement AST macros and it should stop. :-) Until then the library solutions are often unpalatable. Like using string mixins to implement properties. Ick. But the call for a memoization thingy I just don't get. No way that should be a compiler feature, just far too many ways to memoize with too many different tradeoffs. And a memoizing wrapper function basically loses nothing in terms of expressiveness. --bb