DIP 50 - AST macros

[luka8088]

On 21.11.2013. 8:28, Jacob Carlborg wrote:
> On 2013-11-20 23:25, luka8088 wrote:
> 
>> If I understood you correctly, the issue with current way DSLs are
>> implemented is that code needs to be parsed two times. First time DSL
>> author parses it and creates D code from it, and second time D compiler
>> parses that D code and compiles it. What I would suggest in this case is
>> that instead of intercepting the compiler and "fixing" the semantics
>> before it is verified we allow the user to build D Ast and give it to
>> the compiler. That is why I used the mixin in my example.
>>
>> Ast dCodeAst = dslToD!(q{
>>    if true
>>      do()
>>    else
>>      dont()
>>      dont2()
>>    whatever()
>> });
>>
>> // manipulate dCodeAst
>>
>> mixin(dCodeAst);
>>
>> The point of this example is that mixin() accepts Ast instead of string.
>> That way, we parse our DSL to D Ast and give it straight to the compiler
>> and everything is done only once!
> 
> So how is this different except for my proposal, except the use of q{}
> and "mixin"?
> 

When using q{} compiler treats the contents as a regular string, and you
have to parse it and give it to the compiler using "mixin". So basically
you can say to the compiler: this part of code is my DSL and I will
parse it and check the semantics instead of you, then when I am done I
will give you D AST represantation of it.

The interpretation of the content of q{} is up to you, where in other
proposals compiler builds AST based on, I would say, guessing.

Take a look at this last example. And lets say that it is from python.
In python dont2() belong inside else block. So how else would you make
sure that compiler behaves accordingly?