DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky

[Dicebot via Digitalmars-d-announce]

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 
concerns here:

1)

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.

2)

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.