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

["Rémy J. A. Mouëza"]

Andy, is there a particular reason why you don't use the array 
concatenation operator in your select ( and others ) function(s) ?
Like this one :
# ArrayT [] select ( ArrayT ) ( ArrayT [] array, bool delegate ( ArrayT 
) predicate )
# {
#     ArrayT [] result ;
#
#     foreach ( item ; array )
#         if ( predicate ( item ))
#             result ~= item ;
#
#     return result ;
# }


Andy Knowles a écrit :
> 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