On 23 November 2011 21:21, Peter Alexander <peter.alexander.au at gmail.com>wrote:
> On 23/11/11 6:10 PM, Manu wrote:
>
>> Perhaps if you declared some function as lazy, then the compiler
>> would
>> be expected to cache the return value
>>
>>
>> How does it cache it?
>>
>> i.e.
>>
>> - What data structure does it use?
>> - Is there a size limit, or does it just keep adding into the cache
>> until you run out of memory?
>> - What allocator does it use?
>> - If there is a size limit, what is the eviction policy?
>> - and what is the size limit?
>> - How do I manually flag the cache as dirty if I want to clear it?
>>
>> There is no automatic way to do caching. Every single application of
>> caching has its own needs and you need control over that. You can't
>> just stick it all in a hash table and be done with it.
>>
>>
>> I can imagine many possibilities. Here's one straight off the top.
>>
>> - The data structure is the return value of the function contained
>> within its parent class/struct + any necessary dirty bits. Where you
>> place those it in the containing class/struct is debatable, but sensible
>> options exist.
>>
>
> This simply doesn't work for functions of arguments that require caching.
>
> class FooManager
> {
> class Foo { ... }
>
> const(Foo) getFoo(int i) const
> {
> return new Foo(i);
> }
> }
>
> Assume that constructing a Foo is expensive. How can I cache the values of
> Foo? One approach would be to use an array:
>
> class FooManager
> {
> class Foo { ... }
>
> const(Foo) getFoo(int i) const
> {
> if (m_foos[i] is null)
> m_foos[i] = new Foo(i); // illegal in D
> return m_foos[i];
> }
>
> const(Foo)[kCacheSize] m_foos;
> }
>
> Of course, this requires knowledge of the range of 'i' that can be
> received, so there is no way to automate this type of caching.
>
> You could automatically use a hash map, but that is needlessly
> inefficient. Also, what if getFoo could be called with any value of i? You
> wouldn't want to cache all values, you'd just want to cache a subset using
> some eviction policy, perhaps the 10 most recently used values of 'i'?
>
> There's no way to automate caching. One size does not fit all.
This isn't a typical lazy evaluation. In your example, the problem exists
irrespective of the const implementation. I don't think it addresses the
topic.
I'm talking about calls to the same function returning same result every
time. So yes, functions with no arguments.
I can sort of imagine it might be possible to implement my proposal though
even in your case where it receives an index and internally chooses from a
set (each having their own associated dirty flag), but where it uses an
argument to produce the output that may change every time... this is not
lazy evaluation, it's functional evaluation.
> - Size limit? What is the size limit of the object returned from the
>> function in the first place?
>> - Not really relevant, if it's a primitive type or struct, it is
>> contained by the functions containing object, if it is a class, then it
>> is a reference to, and it is allocated however the lazy function does.
>> - I don't think this is relevant.
>> - Again...
>> - Fair question. Perhaps the function could have a property, or the
>> containing class could have some property to access the cached object...
>> but I would imagine the compiler would explicitly manage dirtying of the
>> state, so that it can enforce that it is done in a '@safe' way...
>>
>
> All these responses assume that the function is not a function of its
> arguments (or it has no arguments).
Correct. Lazy/cached evaluation of some slow method.
Am I wrong in suggesting that this is the most frequent cause of people
>> raising the "D const issues' topic?
>>
>
> Yeah, it usually comes down to caching (or lazy computation, which is
> similar) but it's not the only thing.
>
> Essentially, any object that contains state that is not related to its
> definition of equality is difficult to model using D's const qualifiers.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111123/53a7bac3/attachment.html>