But... I don't want my delegates to be lazy - breeding advice

Walter Bright newshound at digitalmars.com
Tue Aug 22 17:26:12 PDT 2006


Tom S wrote:
> Walter, if you *really* want to keep lazy expression evaluation in its 
> current form, then please *at least* don't force everyone to use it.
> 
> Adopting delegate function parameters for lazy expressions is a mistake. 
> At least consider adding a new keyword, e.g. 'lazy' or 'expression', 
> please. The syntax could look like:
> 
> void foo(int expression() foo) {
> }
> 
> or
> 
> void foo(lazy int foo) {
> }
> 
> or just some other variant. Delegates would then be delegates and 
> wouldn't accept lazy expressions. But lazy expressions could accept 
> delegates.
> 
> 
> The above approach has three significant advantages over the current 
> state of things:
> 
> 1. When the coder doesn't intend to use lazy expression evaluation, 
> his/her functions that take delegates as params won't silently accept 
> lazily evaluated expressions
> 2. Less existing code will be broken or the changes will be easier to 
> fix - renaming the keyword to some other variable name compared to the 
> nontrivial fixes that have to be done now.
> 3. In future, the 'expression' or 'lazy' types might provide meta-data 
> allowing advanced metaprogramming techniques
> 
> The third point is important because lazy expressions in their current 
> form simply can't replace expression templates. Even by looking at the 
> first resource available on google...
> 
> http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
> 
> ... it's clear that one of the most important points behind expression 
> templates is the ability to deconstruct expressions and basing on their 
> internal structure, generate highly optimized code. At least that's what 
> game developers use to make their linear algebra libraries as fast as 
> possible.
> This is only possible by knowing the structure of the expression and 
> applying localized and specialized optimizations.
> 
> The 'expression' or 'lazy' types might work in a similar way. They would 
> allow the programmer to inspect parse trees at compile-time and generate 
> specially tailored code.
> 
> Currently the only performance advantage that can be accomplished with 
> lazy expression evaluation is when the compiler determines the delegate 
> might be inlined, which currently doesn't happen at all.

I think this is probably the most sensible proposal yet. Let me think 
about it a bit.



More information about the Digitalmars-d mailing list