What are AST Macros?

[retard]

Mon, 12 Jul 2010 14:57:35 +0000, pillsy wrote:

> == Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
>> On Mon, 12 Jul 2010 09:33:34 -0400, Ellery Newcomer
>> <ellery-newcomer at utulsa.edu> wrote:
> [...]
>> > I think the big thing about macros is you don't have to worry about
>> > lexing and parsing.
> 
>> > if <A> is of the form (Assignable, Assignable, ... ), and <B> of the
>> > form (AssignExp, AssignExp, ... )
> 
>> > how do you readily rewrite
> 
>> > mixin("<A> = <B>;");
> 
>> > to
> 
>> > (<A>[0] = <B>[0], <A>[1] = <B>[1], ... )
> 
>> > without a metric shit ton of library support?
> 
>> > With the most bare bones of AST macros (maybe a ctfe function that
>> > gets passed a AST* and returns a AST* or something equivalent), it's
>> > pretty trivial. And you don't need to wrap it in a string literal.
> 
>> But is that common? Is there a common need to parse mixin strings and
>> replace with other strings?
> 
> In my experience with Lisp macros (which are fundamentally AST macros)
> doing that sort of thing is fairly common when it's easy.
> 
>> Even if it is, can't a string
>> mixin system do exactly that?
> 
> I think it can, actually. Having library functions pick up the slack may
> not be a terrible idea at all. Parsing a string into an AST is just a
> function, transforming that AST into another AST is a function, and
> transforming the resulting AST back into a string that gets mixed in is
> a third function.

Yes, this would be possible if the dmd compiler didn't crash, leak memory 
etc. The quality is so shitty that I'd say that implementing a compile 
time AST parser for D 2 is almost impossible. And what's worse is that 
the language is changing constantly so the AST parser meta-library would 
need to be updated once in a while. This is great news for all the fans 
of NIH syndrome.

> 
> I see two problems with this plan, both which may be addressable without
> too much trouble.
> 
> One problem is that string mixins look terrible, what with them being
> string literals. Having some sort of syntactic support for using macros
> would be a major improvement. I liked your "macro" keyword suggestion
> from elsethread.
> 
> It requires a lot of straight-up hackery. Consider retard's suggested
> way for creating a unique name. Being able to do this is crucial to
> writing macros that simultaneously do non-trivial things and are robust,
> and the inability to create unique names is one reason C preprocessor
> macros are so lame. It would be far nicer if you could use some sort of
> __traits form to get a unique name (and then that could be wrapped in a
> string-mixin macro)!
> 
>> Also, to me, it's trivial to understand string manipulation where the
>> end result is the language I already know, vs. having to learn how the
>> compiler represents syntax.
> 
> String manipulation scales very poorly, it's error prone, and it's
> tedious.

Like Andrei said, real AST macros can also be hairy, but they _are_ an 
improvement over string based macros in many cases. Lisp users have 50+ 
years of experience with meta-programming. You're mostly talking with 
amateurs here. Of course they don't see the value of true macros. One 
fundamental prerequisite when discussing macros is that you've actually 
used them in at least ONE other language.