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

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



Amen

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

Yes, I agree.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

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

Hear hear, I agree 100%.

 - Gregor Richards

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.

What he said :-p


Sean

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 a keyword might be appropriate here, so as to ease the pain of current C/C++ programmers moving to the Light side.

While I am shooting my mouth off, let me chime in with those who think the *auto* keyword should be *var* for automatic type inferencing.

I know keywords should be used sparingly but these are fairly big features.

-DavidM

David Medlock wrote:
> I agree a keyword might be appropriate here, so as to ease the pain of current C/C++ programmers moving to the Light side.
> 

IMHO it has nothing to do with C/C++ programmers moving over.  It's bad because:

1) It's not intuitive to cast expressions into anonymous delegates.

2) It causes ridiculous overload issues:
class A {...}  class B : A {...}
void q(A a); void q(void delegate() a);
void whatever() {
  B b = new B();
  q(b); // this should not be ambiguous, but is
}

3) If I understand, the expression will be evaluated multiple times, once every time you use it in the function, unless you copy it into a different value, which is just painful.

 - Gregor Richards

On Tue, 22 Aug 2006 18:39:57 +0100, 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 agree completely.

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.

Tom S escribió:
> 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 think some things are over my head, but I have the feeling this makes sense. Besides, everyone else has agreed :D

-- 
Carlos Santander Bernal