www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - suggestion: relaxing reqirements for version and mixin

reply "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Quote from: http://www.digitalmars.com/d/mixin.html
 Unlike a template instantiation, a template mixin's body is evaluated

 scope where the mixin appears, not where the template declaration is

 It is analogous to cutting and pasting the body of the template into the

 of the mixin.

In my view it would be realy nice to allow the following code: template Foo(){ return: } void doFoo(){ mixin Foo; } Ok, that's a trival excample but should give you the idea. The content of the version expression should only be interpreted after validating the scope of "version". e.g. if( version(STRICT){a<200 || } a>0){ // blabla }
Jul 26 2004
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:

<snip>
 In my view it would be realy nice to allow the following code:
 
 template Foo(){
     return:
 	}
 
 void doFoo(){
     mixin Foo;
 }
 
 Ok, that's a trival excample but should give you the idea.
 
 The content of the version expression should only be interpreted
 after validating the scope of "version". e.g.
 
 if( version(STRICT){a<200 || } a>0){
     // blabla
 }

Both those features smack of textual processing to me. "Modern languages should not be text processing, they should be symbolic processing." And a potential parsing nightmare. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jul 26 2004
parent reply "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Stewart Gordon wrote:
 In my view it would be realy nice to allow the following code:

 template Foo(){
     return:
 }

 void doFoo(){
     mixin Foo;
 }

 Ok, that's a trival excample but should give you the idea.

 The content of the version expression should only be interpreted
 after validating the scope of "version". e.g.

 if( version(STRICT){a<200 || } a>0){
     // blabla
 }

Both those features smack of textual processing to me. "Modern languages should not be text processing, they should be symbolic processing." And a potential parsing nightmare.

They might sound like nightmare to you :) I'll try to explain the situation I am currently in: situation: An complex if/else block: aprox. 30 different cases, maximum depth 4. While the case handling is always the same the conditions for those cases differ slightly depending on the "lax" or "strict" version. solution 1: Write 2 different functions both containing the same functionality but slightly different case determination. pro: Compatible with current D. No extra computing costs(see solution 2). contra: difficult maintenance - risk to fix e.g. the "strict" but not the "lax" version solution 2: Precalculate part of the if conditions before the actual "if". pro: Compatible with current D. contra: High computing cost of unrequired calculations. solution 3. Write code with Pre-processing through an external preprocessor. pro: easy maintenance; No extra computing costs(see solution 2). contra: incompatible with "plain" D. Stewart, you are invited to present me a true "D" solution that is a) easy to maintain and b) has the best performance possible Thomas
Jul 27 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:

<snip>
 solution 3.
 Write code with Pre-processing through an external preprocessor.
 pro:
 easy maintenance; No extra computing costs(see solution 2).
 contra:
 incompatible with "plain" D.

What you're effectively doing is turning version into a preprocessor.
 Stewart, you are invited to present me a true "D" solution that is
 a) easy to maintain and
 b) has the best performance possible

Possibility 1: Assuming a is of type int, then version (STRICT) { const int UPPER = 200; } else { const int UPPER = int.min; } if (a < upper || a > 0) { ... } Possibility 2: version (STRICT) { if (a < 200 || a > 0) doStuff(); } else { if (a > 0) doStuff(); } where doStuff would typicaly be a nested function. Presumably the compiler would inline it. Possibility 3: realise that your disjunction of conditions is tautologically true, and simplify it to version (STRICT) { const int LOWER = 1; } else { const int LOWER = int.min; } if (a >= lower) { ... } or version (STRICT) { doStuff(); } else { if (a > 0) doStuff(); } Possible idea for D improvement: to invent a VersionExpression, enabling stuff like if (version(STRICT) ? true : (a > 0)) { ... } Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jul 27 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:

<snip>
     version (STRICT) {
         const int UPPER = 200;
     } else {
         const int UPPER = int.min;
     }
 
     if (a < upper || a > 0) { ... }

Oops ... NTS, that was meant to be if (a < UPPER || a > 0) { ... } and similarly with the other instance. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jul 27 2004
prev sibling next sibling parent Sha Chancellor <schancel pacific.net> writes:
In article <ce2col$ikr$1 digitaldaemon.com>,
 "Thomas Kuehne" <eisvogel users.sourceforge.net> wrote:

 Quote from: http://www.digitalmars.com/d/mixin.html
 Unlike a template instantiation, a template mixin's body is evaluated

 scope where the mixin appears, not where the template declaration is

 It is analogous to cutting and pasting the body of the template into the

 of the mixin.

In my view it would be realy nice to allow the following code: template Foo(){ return: } void doFoo(){ mixin Foo; } Ok, that's a trival excample but should give you the idea. The content of the version expression should only be interpreted after validating the scope of "version". e.g. if( version(STRICT){a<200 || } a>0){ // blabla }

While I think versions should allow for expressions in the version condition and version identifiers be integers you could compare against. I don't really think that's necessarily something you should want to be doing with a version. Although it should be allowed..
Jul 26 2004
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Thomas Kuehne wrote:
 if( version(STRICT){a<200 || } a>0){
     // blabla
 }

version (STRICT) const strict = 1; else const strict = 0; ... if ( (strict && a < 200) || a > 0) { ... } Constant folding will take care of eliminating unneeded extra tests.
Apr 03 2007