Will macros just be syntactic sugar?

[Don Clugston]

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