What are AST Macros?

[Steven Schveighoffer]

On Mon, 12 Jul 2010 20:00:12 -0400, pillsy <pillsbury at gmail.com> wrote:

> == Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article:
>
>> On Mon, 12 Jul 2010 16:22:28 -0400, bearophile  
>> <bearophileHUGS at lycos.com>
>> wrote:
> [...]
>> > In my opinion the std.bitmanip.bitfields souce code is already past  
>> the
>> > decency limit for string mixins, and I hope they will be replaced by
>> > something better.
>> How would AST macros make std.bitmanip.bitfields easier to understand?   
>> I
>> have never seen it before, and I understood it after a couple minutes
>> reading.  I bet the AST version would be actually harder to understand.
>
> That's not such a great example. The problems will start piling up when  
> you have more complicated arguments.
> Say you want your macro to look like it has an argument list with two  
> entries, called like
>
>      foo(x, y)
>
> which acts like a string mixin, and receives "x, y" as the argument  
> string. Then you split at the comma, and
> you're fine.

This isn't exactly what I meant to do with macros.  What I wanted was for  
the commas to separate the expressions, and pass those expressions via  
stringification.  It isn't a fully fleshed out idea, but here is what I  
was thinking:

macro foo(arg1, arg2) mixin("$arg1 + $arg2;") // $ inside string  
references parameter, just a possibility

foo(x, y); // translates to mixin("x + y;");

These are just ideas, perhaps there are issues with them, but I think we  
can come up with reasonable rules that allow a lot of flexibility, and at  
the same time, allow mixins to be masked as normal expressions, resulting  
in greater usability in generic code, and much more beautiful code.

> You go on with your day, and the next thing you know someone is  
> complaining that your foo macro
> doesn't work because it chokes on
>
>     foo(bar(a, b), c)
>
> and
>
>     foo("d, e", f)
>
> By the time you deal with all the possibilities, you'll have written  
> most of a parser. That parser has gotta parse
> the text into *something*, and it'll probably be a tree.

Or, you say "foo isn't meant to deal with that input" :)

I don't see people complaining that bitfields doesn't accept such various  
strings as arguments...

> There's no reason you can't use library functions to parse strings  
> containing D code into that tree; indeed,
> having access to such functions in the standard library would be useful  
> in all sorts of ways. RIght now D is only
> a couple steps away from where it would need to be in order to allow  
> people to build a really useful macro
> system in libraries.

I think a full parser would not hurt, but most of the time, you just want  
to use the expressions in generating some code.  Pulling apart an  
expression and reassmbling it can solve some problems, but the majority of  
the reason to need macros is to generate code, not to read it and rewrite  
it.

-Steve