• Artyom Shalkhakov <artyom.shalkhakov gmail.com> Apr 03 2007
• Artyom Shalkhakov <artyom.shalkhakov gmail.com> Apr 03 2007
• Dan <murpsoft hotmail.com> Apr 03 2007
• Johan Granberg <lijat.meREM OVEgmail.com> Apr 03 2007
• Chris Nicholson-Sauls <ibisbasenji gmail.com> Apr 03 2007

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.

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.

 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.

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. 

Dan wrote:
 Thomas Kuehne wrote:
 if( version(STRICT){a<200 || } a>0){
     // blabla
 }



 "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