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.
Oops, looks like the wrong button. =) Sorry.

> > > 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
>>>>> }
>>>> 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