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.