What are AST Macros?

[Jacob Carlborg]

On 2018-04-09 18:39, Cym13 wrote:
> On Monday, 9 April 2018 at 15:30:33 UTC, Stefan Koch wrote:
>> On Friday, 6 April 2018 at 21:45:45 UTC, Zach Tollen wrote:
>>>
>>> I think Walter's reason was that such macros would hide too many 
>>> idiosyncrasies in how they were programmed, such that a lot of code 
>>> which seems simple on the surface will actually obfuscate complicated 
>>> and arbitrary macro-programming patterns. Thus, code that uses them 
>>> will become much less maintainable, because it is liable to do so 
>>> many different and hidden things. Also, the tasks for which 
>>> AST-macros would typically be used are already largely accommodated 
>>> by templates and other features. Thus, the real need for them isn't 
>>> that high.
>>
>> I think it's time to revisit this.
>>
>> The reason being that templates are only well suited to very specific 
>> types of meta-programs which have a low degree of parameterization and 
>> a low degree of abstraction.
>>
>> Using templates to introspect and manipulate types is like using a 
>> hammmer's flat back to remove a nail.
>> It _can_ be done but with an absurd amount of work.
>> You just have to remove all of the wall around the nail by pounding it 
>> until the wall has around the nail is disintegrated :)
>>
>> This is not an exaggeration.
>>
>> Templates used for introspection (or anything else really that's 
>> modestly complex) are equally hard to reason about for compilers and 
>> for programmers. I guess programmers have an advantage when it comes 
>> to _efficient_ pattern recognition.
> 
> Wouldn't AST macros require either to standardize (and freeze) AST 
> representation within the compiler or to maintain an equally frozen 
> alternate representation to be exposed?

Yes. It can have two separate ASTs, one internal for the compiler and 
one external that are used together with the AST macros. They would 
probably quite similar but they don't need to be exactly the same.

> I can't see how that wouldn't 
> make the compiler's development slower since all of a sudden changing 
> the internal representation would impact user code, especially given the 
> low number of breaking changes that are accepted today.

We already have three clients using the AST: LDC, GDC and the DMD Dub 
package.

-- 
/Jacob Carlborg