Will macros just be syntactic sugar?
Davidl
Davidl at 126.com
Wed Apr 25 02:28:07 PDT 2007
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);
>>> :
>>> ------------
>>
>
More information about the Digitalmars-d
mailing list