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


within the

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


defined.

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


location

 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) { ... }


<snip>

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


 within the

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


 defined.

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


 location

 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 next sibling parent reply Artyom Shalkhakov <artyom.shalkhakov gmail.com> writes:
Stewart Gordon Wrote:


 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.


Thanks for the tips. I'm off to read the articles you mentioned.
Apr 03 2007
parent reply Artyom Shalkhakov <artyom.shalkhakov gmail.com> writes:
Artyom Shalkhakov Wrote:


 Stewart Gordon Wrote:
 

 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.


 
 Thanks for the tips. I'm off to read the articles you mentioned.


Oops, looks like the wrong button. =) Sorry.
Apr 03 2007
parent reply Dan <murpsoft hotmail.com> writes:
 Thomas Kuehne wrote:

 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."






To me, that looks like the way it ought to be.

It also makes sense to me to allow:

x = switch(y){  <-- ask me about the implementation
  case 3: 5;
  case 2: 4;
  case 7: 3;
  default: 1;
}

and 

double myFunc(double x)
   return std.math.log2E(x)+1;

for(int i = 0; i < 100; i++)
   x += myArray[i] - (myOtherArray[i] * i);

Why?  

For the latter two, we allow if's to be done that way.  But not for loops or
functions?  Sure it's text processing.  We're feeding the compiler text
instructions!  I agree, it's a bad idea to get into macro'ing - templates are
already too far into that, and I don't use mixins.

These are just sensible completions of the language.
Apr 03 2007
next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Dan wrote:


 Thomas Kuehne wrote:

 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."






 
 To me, that looks like the way it ought to be.
 
 It also makes sense to me to allow:
 
 x = switch(y){  <-- ask me about the implementation
   case 3: 5;
   case 2: 4;
   case 7: 3;
   default: 1;
 }


Why not use match instead of switch to avoid confusion, if it is named
switch people will expect fall-through? It is pater-matching and could be
extended past the current limited matching provided by switch, take a look
at ML if you have not done so.
Apr 03 2007
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Dan wrote:

 Thomas Kuehne wrote:

 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."






 
 To me, that looks like the way it ought to be.
 
 It also makes sense to me to allow:
 
 x = switch(y){  <-- ask me about the implementation
   case 3: 5;
   case 2: 4;
   case 7: 3;
   default: 1;
 }


T match (T, U) (T val, T[U] pairs, T def = T.init) {
   if (auto ptr = val in pairs)
     return *ptr;
   else
     return def;
}

Okay, so it isn't ideal -- and admittedly just came off the top of my head --
but the idea 
is, ultimately, the same.  Maybe it can be leveraged into something more
generally useful? 
  Random thought.  :)


 and 
 
 double myFunc(double x)
    return std.math.log2E(x)+1;


I've got no problem with this at all.  A hypothetical scripting language I
toyed with for 
a few months did something rather like it:
   function myFunc (x) = #Math:log2E(x) + 1;

Note the absence of a 'return' keyword.  The concept was that, in the case of
an 
expression statement, the result of the expression would be automatically
returned.  But 
again, that was for a scripting language, so D may or may not be able to get
away with 
that cleanly.


 for(int i = 0; i < 100; i++)
    x += myArray[i] - (myOtherArray[i] * i);


Okay, I must be dense (quite likely, really) but I don't recall for()
statements not 
allowing bodies without braces?  The specs still describe them as allowing 
single-statement bodies, and my own code has a few of these here and there. 
Did I miss 
something radical?


 Why?  
 
 For the latter two, we allow if's to be done that way.  But not for loops or
functions?  Sure it's text processing.  We're feeding the compiler text
instructions!  I agree, it's a bad idea to get into macro'ing - templates are
already too far into that, and I don't use mixins.
 
 These are just sensible completions of the language.


-- Chris Nicholson-Sauls
Apr 03 2007
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