Lazy evaluation

Timon Gehr timon.gehr at gmx.ch
Tue Nov 22 15:23:16 PST 2011


On 11/22/2011 11:00 PM, Manu wrote:
> So, I've been thinking about this const/lazy evaluation problem again.
>
> I think most of the complaints about D's const is due to the use of lazy
> evaluation for optimisation. I started wondering if there was room for a
> 'lazy' keyword.
> Perhaps if you declared some function as lazy, then the compiler would
> be expected to cache the return value, and also generate its own dirty
> flag, which it may manipulate in its own way. The compiler should have
> all the information it needs within the lazy function to know what
> external influences would cause a dirtying of the state. If they are
> sibling members as is often the case, it should be easy for them to be
> tagged to mark the dirt bit dirty whenever they are modified... if they
> are external non-const factors, then I would expect a warning (or error?).
>
> Just a thought anyway. Curious to know if anything like this has ever
> been considered... It might address the majority of the problems with
> D's const.
> Ie, I imagine a lazy function could also be marked const, and either,
> the compiler would have to just ignore the lazy cache and perform a full
> evaluation when called within a const context, OR it would be the
> responsibility of the compiler to implement the dirty logic in a 'safe'
> way (with respect to thread safety... lock free primitive usage? etc)
>
> Am I insane?
>
> - Manu

I'd say variables would have to be declared as lazy, not functions. Then 
you could set the dirty flag manually on mutable instances. Const 
instances that refer to mutable data would benefit from lazy evaluation 
while immutable instances would have to compute the lazy members during 
their construction. This usage clashes with the current call by name 
semantics of the lazy parameter storage class though.


More information about the Digitalmars-d mailing list