Purity (D2 standard libraries / object.d)

[Bill Baxter]

On Sun, Jan 11, 2009 at 8:51 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Walter Bright wrote:
>>
>> Andrei Alexandrescu wrote:
>>>
>>> Michel Fortin wrote:
>>>>
>>>> On 2009-01-10 00:10:11 -0500, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at 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