Will macros just be syntactic sugar?

[Davidl]

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);
> :
> ------------