On Thursday, 5 December 2013 at 08:17:01 UTC, Jacob Carlborg
wrote:
On 2013-12-04 19:55, Dmitry Olshansky wrote:
I'll just add a bit of my experience on this.
The coolest side of things is that you get to code a
mini-compiler that
has a very nice backend - D code. More then that you get
optimizer and
such for free. Then you only do the fun stuff - your frontend,
and if it
wasn't for CTFE speed/stability the experience is _very_
pleasant.
With AST macros it would be the same thing, just that you don't
need to code the mini-compiler. It's already done for you.
Compare that with writing a fully fledged JIT compiler for
say, regex
patterns. Don't forget to account that you'd need to port it
to X
architectures times Y OS ABIs and generate code of at least
moderate
quality.
JIT would have the benefit of being usable for patterns not
known ahead
of time though.
AST macros would generate a new AST, no need to create a JIT
compiler. The advantage of AST macros is that the compiler
doesn't need to re-lex and re-parse the result.
I think that is of negligible benefit. There's not a whole of
difference between manipulating an AST, vs manipulating text, and
I'm confident that the time taken to do that is always going to
be far more than the time required to lex and parse text.
What AST macros could provide is syntax sugar.
But IMHO there's a lot more to be gained from improvements to
compile time reflection.
