Thread overview | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 22, 2006 But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
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 |
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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
|
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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 |
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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
|
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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
|
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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
|
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Medlock | 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
|
August 22, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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.
|
August 23, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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.
|
August 23, 2006 Re: But... I don't want my delegates to be lazy - breeding advice | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tom S | 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 |
Copyright © 1999-2021 by the D Language Foundation