DIP 50 - AST macros

[Dmitry Olshansky]

13-Nov-2013 01:16, Dicebot пишет:
> On Tuesday, 12 November 2013 at 20:56:34 UTC, Dmitry Olshansky wrote:
>> If we just had:
>>
>> //this would invoke compiler's parser at CTFE
>> auto ast = "x = y;".astof
>>
>> and have it work at CTFE to return sensible AST (a big if btw).
>>
>> And then (after some manipulations):
>> ast.toString() //get back a string of D code
>>
>> It may help code generation of D --> DSL.
>
> Add there "foo.codeof" in the toolset and it will pretty much give core
> needed stuff.
>
> However, it will destroy compilation times if not coupled with compiler
> internal parsing/semantic phase.

For me it feels a lot like implementing something as a soft-core or 
emulator in software vs producing a bare-metal chip. It's a good idea to 
test waters and prototype a soft-thingy before getting dirty. When it 
comes to manufacture ASICs the idea should be well tested and could be 
actually sold as is already ;)

If we consider that compiler is sort of "hardware" accelerator for 
getting ast's of strings and functions alike. Ditto with toString of 
ast. Then if somebody comes up with soft-core implementation of "macros" 
and shows:
a) Cool benefits of manipulating on ASTs compared to cracking some strings
b) Limitations of this implementation (unhyginic is one)
c) Quantify obvious performance problems
d) Prepare a solid file of use cases

Then we might get people to manufacture ASICs (pay costs, implement in 
compiler/spec).

Paraphrasing somebody from C++ ISO committee (I think Herb):

Boost C++ Lambda is a prime reason we had to add lambdas as a core 
feature in C++11. If it took these top-notch experts that much of coding 
to get only this far and it's still brittle, limited and etc.
... we have no choice but to add it to the language.

> Actual "macro" keyword syntax sugar is hardly important to me.


-- 
Dmitry Olshansky