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

[Andy Knowles]

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

I agree, there should be some difference between a delegate and a lazy 
expression.  Besides fixing an overload ambiguity, this would leave the 
door open to extensions to lazy expressions that won't necessarily make 
sense for delegates.

The reason people tout LISP (not that I have used it more than I 
absolutely had to) as having power that other languages do not is not 
the lazy evaluation of expressions but the ability to decompose, examine 
and alter the expression tree using the same code as for any other LISP 
data structure (since they're all the same anyway).

The reason people think Expression templates in C++ are so impressive is 
not lazy evaluation - it's compile-time inline insertion of user code 
into library functions.  So when I write math::integrate(x*x + 2*x + 1, 
x, 0, 3) I know that my quadratic expression is inserted directly into 
the inner-most loop of the integral function and incurs no overhead per 
iteration.

One of C# 3.0's big new features is Expression templates, which is much 
more than syntactic sugar for anonymous delegates (which it already has 
and is improving).  The point is that an expression template is not 
compiled into code but into a data structure that can be explored at 
run-time.  Thus one can write OO-style C# code that gets turned directly 
into an efficient SQL query.

Having said all that, the syntax does open some functional-programming 
doors to D.  I knocked this up while experimenting.  Note the need to 
pass in the expression argument as a separate parameter - something
a => a * 2 could fix (or some other syntax).

http://www.members.iinet.net.au/~melkesjokolade/functional.d

Andy