AST macros

[Walter Bright]

Don Clugston wrote:
> Walter Bright wrote:
>> Don Clugston wrote:
>>> Walter Bright wrote:
>>>> You'll be able to do things like:
>>>>  >>
>>>>  >> macro print(arg)
>>>>  >> {
>>>>  >> writefln(__FILE__, __LINE__, arg);
>>>>  >> }
>>>
>>> This looks great already. However, I don't see any specific "abstract 
>>> syntax tree" syntax in this. Is that still a work-in-progress?
>>
>> The beauty of it is that (a+b), before semantic analysis, is an AST! 
>> So there's no funky new grammar to learn.
> 
> Fantastic! Does this mean that you just use arg.stringof to get the 
> expression? And 'arg' to evaluate it?

I'm not totally sure yet.

> 
>>> An observation:
>>> My version of vector operation expression templates is mostly working 
>>> now, using the existing mixins. It deals with ASTs by constructing a 
>>> string representing the operations to be performed, and a tuple 
>>> containing all of the parameters. The operations string is of the form
>>> "g+=((a+b)*c)+((d*e)+f)", where a, b, c... correspond to T[0], T[1], 
>>> T[2]... of the tuple T.
>>>
>>> A compile-time function converts the string into postfix, and then 
>>> another CFTE function converts that into optimised x87 asm, which is 
>>> mixed in.
>>
>> Wow! I think the macros can help by obviating the need for the user to 
>> do the mixin manually.
> 
> Actually usage is OK already. Here's an example:
> ------
>     auto p = Vec([1.0, 2, 18]);
>     auto q = Vec([3.5L, 1.1, 3.8]);
>     auto r = Vec([17.0f, 28.1, 1]);
>     q -= ((p+r)*18.0L*314.1L - (p-r))* 35;
>     real d = dot(r, p + 3.7*r);
> ------
> And the only reason for Vec() is because otherwise you can't create 
> array operations. In the first stage, the Vector structs returned by 
> Vec() are removed, and only built-in real[], double[], and float[] 
> vectors are put into the tuple.
> BTW the generated asm is really good quality; in each case, it generates 
> the best code I can write by hand.
> 
>>> Unexpectedly, I found that it's actually very nice to have flattened 
>>> tuples. If an AST could recognise that two parameters are the same, 
>>> it could avoid duplication in the tuple, something that a tree can't 
>>> easily do:
>>> eg   somevec+= othervec + somevec*3;
>>> could become "T[1]+=T[0]+(T[1]*3)" which allows better code 
>>> generation in the final stage.
>>
>> There's a way to do this using specialization:
>>
>>     macro foo(somevec : somevec+=othervec+somevec, othervec)
>>
>> which will only match for parameters of the form:
>>
>>     foo( a += b + a);
>>
>>     somevec => a
>>     othervec => b
>>
>> It works analogously to how you can match type patterns in templates 
>> using specializations.
> 
> Now that could be useful...
> Are we going to able to write macros for member functions, and operator 
> overloads?

Probably not.