Lazy evaluation

Manu turkeyman at gmail.com
Wed Nov 23 10:10:52 PST 2011


>
> 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.
- 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...

Am I wrong in suggesting that this is the most frequent cause of people
raising the "D const issues' topic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111123/8e42aa2c/attachment.html>


More information about the Digitalmars-d mailing list