Will macros just be syntactic sugar?

[Davidl]

sorry for typos in the error message :o
should be
        static if (tokens[4].ID != Token.LBracket)
  	pragma(error, `[ expected`);
        else static if (tokens[5].ID != Token.Identifier)
           pragma(error, `identifer expected`);
        else static if (tokens[6].ID != Token.RBracket)
           pragma(error, `] expected`);

> macro (Token... tokens)
> {
>       static if (tokens[0].ID != Token.LParen)
> 	pragma(error, `( expected`);
>       else static if (tokens[1].ID != Token.Identifier)
>          pragma(error, `identifer expected`);
>       else static if (tokens[2].ID != Token.RParen)
>          pragma(error, ) expected`);
>       else static if (tokens[3].toChars != `:=`)
>          pragma(error, `:= expected`);
>       static if (tokens[4].ID != Token.LBracket)
> 	pragma(error, `( expected`);
>       else static if (tokens[5].ID != Token.Identifier)
>          pragma(error, `identifer expected`);
>       else static if (tokens[6].ID != Token.RBracket)
>          pragma(error, ) expected`);
>       else static if (tokens[7].ID != Token.Identifier)
>          pragma(error, `identifer expected`);
>       else static if (tokens[8].ID != Token.plus)
>          pragma(error, `+ operator expected`);
>       else static if (tokens[9].ID != Token.Identifier)
>          pragma(error, `identifer expected`);
>       alias token[1] arg0;
>       alias token[5] arg1;
>       alias token[7] arg2;
>       alias token[9] arg3;
>       arg0[arg1] = arg2 + arg3;
> }
>
> seems the above is more valuable.
>
>> numerle's macro is somewhat worth consideration
>> an improved syntax should be something like:
>> macro macroname(arg0,arg1,arg2,arg3)
>> syntax realname(arg0)[arg1] := arg2 +arg3
>> {
>>     arg0[arg1] = arg2+arg3;
>> }
>>
>> and calling style would be realname(a)[i] := j + k; // which would call  
>> macro macroname(a,i,j,k)
>>
>>>
>>> A couple of weeks ago, I posted an implementation of BLAS1-style  
>>> vector expressions, that used tuples and expression templates to  
>>> generate near-optimal asm code in many circumstances. Unfortunately,  
>>> when I've looked at the code that is generated, there's a *hideous*  
>>> amount of stack shuffling -- it is too difficult for the compiler to  
>>> optimise all the tuple operations away.
>>> So I came up with this alternative, which gives _many_ more  
>>> optimisation opportunities, and doesn't require you to wrap arrays of  
>>> built-in types.
>>>
>>> float [] vec1 = [43, 5445, 547, 465];
>>> auto vec2 = [1.24, 765, 6756, 23.143];
>>>
>>> mixin(vectorize("vec2+=vec1*3.3254"));
>>>
>>> This actually works. There are some awesome side effects -- eg, any  
>>> error messages in the library code appear on the line of user code.  
>>> You can determine which of the variables are compile-time constants  
>>> (and optimise the generated code based on the value of those  
>>> constants). You can get the compiler to do _most_ of the heavy lifting  
>>> (eg, convert floating point strings <--> const real).
>>>
>>> As far as I can tell, *all* of the proposed 'macro' functionality can  
>>> be done already using mixins and CTFE. It looks as though the power of  
>>> macros will be a subset of the power of mixins. This means that macros  
>>> can be explored quite thoroughly *before* deciding on the cleanest  
>>> syntax for them.
>>>
>>> Today:
>>> ---------
>>> char [] magic(char [] args)
>>> {
>>>     return "stuff-to-mix-in";
>>> }
>>>
>>> :
>>>    mixin(magic("a+=b*c"));
>>> :
>>> -----------
>>> With macros:
>>>
>>> macro magic(args)
>>> {
>>>    stuff-to-mix-in
>>> }
>>>
>>> :
>>> magic(a+=b*c);
>>> :
>>> ------------
>>
>