DIP 50 - AST macros

Jacob Carlborg doob at me.com
Wed Nov 13 00:02:18 PST 2013


On 2013-11-12 10:20, Walter Bright wrote:

> I confess I have some serious reservations about AST macros in general:
>
> 1. I've seen very heavy use of such macros in macro assemblers. What
> happens is people use it to invent their own (very baroque) language on
> top of the existing assembler one. Anyone trying to read the code has to
> learn this new unique language, and given the limitations of the macro
> capability, it often comes with unfixable bizarre corner cases and
> limitations.

There's a word for that, it's called DSL (Domain Specific Language) :)

> This got so bad that in some cases I know of, the poor sap who is given
> the job of making improvements resorted to running the assembler to
> generate an object file, then disassembling the object file back into
> source code! Something went very wrong for this to be necessary. I know
> in my own assembler work I have abandoned all use of macros.

DSL's are so popular so many languages are specifically designed to make 
it easy to create DLS's.

> (Note that macros in typical assemblers are far more powerful than C's
> macro language, which stands out for being pathetically underpowered.)
>
> 2. Macros are something that should be used very sparingly. However,
> this is not what happens. I used to be perplexed that even top shelf
> C/C++ programmers tend to write what I not so humbly consider to be
> pretty abusive use of macros. Now it just saddens me.

It depends on what kind of macros we're talking about. For C 
preprocessor macros, absolutely. But just because to different features 
have the same word "macro", you shouldn't put the in the same box. I 
guess I shouldn't have used the word "macro" at all in the DIP.

> 3. Lisp is a language that encourages users to write macros to pretty
> much invent a custom language for the task at hand. Heavy use of such
> makes the code unrecognizable as being Lisp code. I believe a language
> ought to have some "anchors" that the person reading the code can
> reliably recognize. (GO has taken this idea pretty far.)

Lisp doesn't have any syntax to begin with.

> 4. AST macros, pretty much by definition, manipulate the AST. However,
> if you examine the semantic routines in DMD, a *lot* more is required to
> do more significant things. The symbol table must be consulted, etc. I
> just don't see how one could hope to implement something like function
> overloading with AST macros. Or template type deduction. Or closure
> semantics, attribute inference, etc. Sure, some forms of foreach can be
> rewritten into for statements by manipulating the AST, but not the more
> interesting forms, such as the ones that deal with opApply().

Macros are not for implementing function overloading or template type 
deduction, we already have those features. I don't consider these easy 
to implement and they're not lowered in the same way as "scope" or 
"foreach" are.

> There are some statements in the DIP about the Context parameter and
> it'll provide semantic information, but I don't see how this can work
> without making it an ever-expanding collection of arbitrary methods.

We'll just put in what we want and need there. At the worst case you'll 
get access to the whole compiler. Which is what we want any way, at 
least the front end, to be usable as a library.

> 5. We've said "no" in the past to things like user-defined tokens, which
> are closely related.

No, they're not.

> 6. Note that D has a limited form of AST macros with mixin templates.

Yes, I do know. Note that they are too limiting compared to AST macros.

> To sum up, any AST macro proposal has some tough barriers to get over.
> Within its necessarily severe semantic limitations, it has to deliver a
> pretty compelling set of solutions, while avoiding the morass of
> incomprehensibility that far too many macro systems become in practice.

Note that AST macros (according to the DIP) is not anything like C 
preprocessor macros. Basically the only thing they have in common is the 
name, "macro". It's not a valid comparison.

C macros are textual macros. They can create completely new syntax. AST 
macros cannot. They work at the semantic level in the compiler, just as 
templates. They can add new semantic meaning to existing syntax. Just 
like templates, macros need to lex and parse correctly. Templates do not 
need to be semantically correct if they're not instantiated.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list