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