Lazy evaluation

[Timon Gehr]

On 11/23/2011 12:53 AM, Jonathan M Davis wrote:
> On Wednesday, November 23, 2011 00:23:16 Timon Gehr wrote:
>> 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.
>
> This basic idea was discussed a couple of months back, and it was determined
> that it was overly complicated for very little gain.
>
> - Jonathan M Davis

I strongly disagree.