What are AST Macros?

[Steven Schveighoffer]

On Mon, 12 Jul 2010 19:21:08 -0400, Nick Sabalausky <a at a.a> wrote:

> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
> news:op.vfq0aydoeav7ka at localhost.localdomain...
>> On Mon, 12 Jul 2010 16:22:28 -0400, bearophile  
>> <bearophileHUGS at lycos.com>
>> wrote:
>>
>>> Steven Schveighoffer:
>>>> bearophile:
>>>> > String mixins are a hack, just a bit better than C preprocessor
>>>> (because
>>>> > they are scoped), they are not a replacement of clean macros.
>>>>
>>>> Interesting statement, can you back it up? :)  What can you do with a
>>>> macro that you can't do with a mixin?
>>>
>>> In the meantime others have already given you some answers, I can add
>>> one example. The Brainfuck language allows you to do every kind of
>>> thing, I have seen even compilers written in it, but its usage is very
>>> unhandy, it's bug-prone, requires lot of code to do even simple things,
>>> and it's very hard to modify and debug programs written in it. What I
>>> meant is that string mixins in theory allow you to do many things, but
>>> in practice you can't use them for complex tasks, and you can't modify
>>> and fix the resulting code if you try to use them for more complex
>>> tasks. They are not a long-term solution for a language that seriously
>>> wants to improve over C and its preprocessor macros, they are a hack.
>>
>> Brainfuck is basically a toy example of a language.  Nobody uses it for
>> serious work.  Mixins are much better than a hack, the syntax of using
>> them is just not polished.  They are easy to use/understand because a)
>> people understand the language and b) people understand string
>> manipulation.
>>
>
> But when you're talking about the string being actual code, you're not
> always talking about typical string manipulation, sometimes you're  
> talking
> about parsing which is only "string manipulation" superficially.

Not in most cases.  For extremes, I think perhaps there could be a niche  
for that, but it can be had via string mixins and CTFE (as long as CTFE is  
robust enough).  Having a compiler written in D wouldn't hurt either ;)

>
>>
>> I'll give you another example -- javascript and HTML editing.  Most  
>> people
>> would prefer to just use the innerHTML component of an element than have
>> to use the DOM methods to create individual elements and add them as
>> children, etc.
>>
>
> For writing, yes, but there's also reading: How many people do you know  
> who
> would rather find the elements they want by parsing innerHTML instead of
> just dealing with the readily-available tree? None, I would hope, but the
> latter is essentially what we have to do for many of the more advanced
> things that string mixins *technically* replace AST macros for.

But you can't manipulate D code "on the fly" as you can HTML.   
Essentially, you are *always* writing code when using string manipulation  
to do mixins, because the compiler hasn't parsed it yet.

Essentially, there is no requirement that the input that you are about to  
manipulate must be valid D code, only the output should be.  That isn't to  
say it can't be valid D code, but in most cases, wouldn't you rather have  
simpler input?

-Steve