On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote:
This one thing I'm loosing sleep over - what precisely is so
good in CTFE code generation in _practical_ context (DSL that
is quite stable, not just tiny helpers)?
By the end of day it's just about having to write a trivial
line in your favorite build system (NOT make) vs having to wait
for a couple of minutes each build hoping the compiler won't
hit your system's memory limits.
Oh, this is a very good question :) There are two unrelated
Reflection. It is less of an issue for pure DSL solutions because
those don't provide any good reflection capabilities anyway, but
other code generation approaches have very similar problems.
By doing all code generation in separate build step you
potentially lose many of guarantees of keeping various parts of
your application in sync.
Moving forward. You use traditional reasoning of DSL generally
being something rare and normally stable. This fits most common
DSL usage but tight in-language integration D makes possible
brings new opportunities of using DSL and code generation
casually all other your program.
I totally expect programming culture to evolve to the point where
something like 90% of all application code is being generated in
typical project. D has good base for promoting such paradigm
switch and reducing any unnecessary mental context switches is
very important here.
This was pretty much the point I was trying to make with my DConf
talk ( and have probably failed :) )
And these couple of minutes are more like 30 minutes at a
times. Worse yet unlike proper build system it doesn't keep
track of actual changes (same regex patterns get recompiled
over and over), at this point seamless integration into the
language starts felling like a joke.
And speaking of seamless integration: just generate a symbol
name out of pattern at CTFE to link to later, at least this
much can be done relatively fast. And voila even the clunky
run-time generation is not half-bad at integration.
Unless things improve dramatically CTFE code generation + mixin
is just our funny painful toy.
Unfortunately current implementation of frontend falls behind
language capabilities a lot. There are no fundamental reasons why
it can't work with better compiler. In fact, deadlnix has made a
very good case for SDC taking over as next D frontend exactly
because of things like CTFE JIT.