Mixin template evaluated to string can convert to string mixin expression implicitly

[Timon Gehr]

Alex_Dovhal wrote:
> "Timon Gehr" <timon.gehr at gmx.ch> wrote:
>> Macros operate on ASTs, not strings. You won't get real macros, just
>> something
>> that feels somewhat like them. You still could implement the equivalent to
>> C
>> macros (not real macros either) in a library, but they would have all the
>> problems
>> of C macros, as string mixins do now. (You make this fact explicit by
>> typing "mixin").
>>
>> For anything but the most trivial code transformations, you have to cheat
>> the
>> compiler into parsing your code into an AST (further complicated by the
>> fact that
>> you cannot overload all operators freely), use clever tricks to get the
>> information you want and then you have to transform it back into a string
>> so that
>> it can then be mixed in (which of course requires reparsing the whole
>> thing.) This
>> is just painful and a waste of cycles.
>> String mixins are useful, but they cannot replace macros.
>>
>> What would your library be capable of?
>
> Yes. Library macros can build AST with CTFE :)

My question could not possibly be answered with 'yes', actually I was interested
in what functionality your library would provide for the end user.
You answered the question "Would your library be capable of building an AST?".

>
> About Library interface, one sample:
>
> template macroFunct(string T)
> {
>     enum macroFunct = macroFunctImpl(T);
> }
>
> string macroFunctImpl(string arg)
> {
>     auto ast = parseAST_1(arg);
>     // do something. e.g.
>     return ast[0];
> }
>
> /*AST, here string[]*/ string[] parseAST_1(string arg)
> {
>     //do something. e.g.
>     return [arg];
> }
How do you want to store your AST in a string[]? (Yes, it works, if you want some
really hacky, ugly and overlong code.)


>
> int main()
> {
>     assert(mixin(macroFunct!q{123})==123);
>     assert(! (mixin(macroFunct!q{321})==322));
>
>     return 0;
> }
>

You did not fill out the function bodies because that would be a PITA and some
n*1000 lines long, right?
Lexing and parsing code should be the compiler's business.
You want to use a compiler to interpret code that then parses other code into an
AST, that is then mutated and then converted back to a string, just that the
compiler's native parser can parse it again.
The fact that it could be made to work does not mean it is a good idea. :)

Cheers,
-Timon