What are AST Macros?

[Nick Sabalausky]

"Don" <nospam at nospam.com> wrote in message 
news:i1h6br$2ngl$1 at digitalmars.com...
> Rainer Deyke wrote:
>> On 7/13/2010 01:03, Nick Sabalausky wrote:
>>> "Rainer Deyke" <rainerd at eldwood.com> wrote in message 
>>> news:i1gs16$1oj3$1 at digitalmars.com...
>>>> The great strength of string mixins is that you can use them to add the
>>>> AST macros to D.  The great weakness of string mixins is that doing so
>>>> requires a full (and extendable) CTFE D parser, and that no such parser
>>>> is provided by Phobos.
>>> Seems to me that would lead to unnecessary decreases in compilation 
>>> performance. Such as superfluous re-parsing. And depending how exactly 
>>> DMD does CTFE, a CTFE D parser could be slower than just simply having 
>>> DMD do the parsing directly.
>>
>> True. I tend to ignore compile-time costs.  The performance of computers
>> is increasing exponentially.  The length of the average computer program
>> is more or less stable.  Therefore this particular problem will
>> eventually solve itself.
>>
>> Of course, this is just my perspective as a developer who uses a
>> compiler maybe twenty times a day.  If I was writing my own compiler
>> which was going to be used thousands of times a day by thousands of
>> different developers, I'd have a different attitude.
>>
>>
>
> CTFE isn't intrinsically slow. The reason it's so slow in DMD right now is 
> that the treatment of CTFE variables is done in an absurdly inefficient 
> way.

Doesn't it at least have some intrinsic overhead? The best way I can think 
of to do it (in fact, the way Nemerle does it, and I really wish D did too) 
is to actually fully compile the CTFE then dynamiclly link it in and run it 
natively (erm, well, Nemerle is .NET, not native, but you get the idea). 
Even that would seem to have a little bit of overhead compared to just 
running code that's already built-in to the compiler (it has to compile a 
chunk of code, and then link it, both of which take more time than just 
calling an internal function). And if you're not doing it that way then 
you're interpreting, which inherently adds some fetch/dispatch processing.

Yea, certainly it could be made to be fairly fast, and the overhead doesn't 
*have* to be big enough to be noticable. But why not just do it the *really* 
fast way right from the start? Especially in a language like D that's 
supposed to have an emphasis on short compile times.