Alex_Dovhal wrote: > "Timon Gehr" <timon.g...@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