DIP 50 - AST macros

Martin Nowak code at dawg.eu
Tue Nov 12 15:50:21 PST 2013


On 11/12/2013 10:20 AM, 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.
>
Yes, this is a big issue.
I have similar concerns about UDA, but it's easier to put the most 
needed UDAs into phobos making them more standardized.

> 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().
>
That's the question we'd have to answer.
I think what we should target for is that constructs like async/await or 
SIMDifying of code can be implemented using AST macros.

> For example, the Linq example in the DIP is not compelling, as
> aesthetically nicer code can be written using D's ranges and algorithms:
>
>      auto data = arr.filter!(x => x > 5).array;
>
> I see no compelling advantage in trying to make D code look like C#; to
> be blunt it's like the old:
>
>      #define BEGIN {
>      #define END }
>
> macros used in old C code to make it look like Pascal.
>
True


More information about the Digitalmars-d mailing list