On Tuesday, 13 March 2018 at 17:33:14 UTC, H. S. Teoh wrote:
Now usage:

alias powMod = bluePrint.instantiate; // here we do optimizations and CTFE-based codegen

powMod(a,b,c); // use as many times as needed

Wouldn't CTFE-based codegen be pretty slow too? Until newCTFE is merged, it would seem to be about as slow as using templates (if not slower).

Trying to do even most basic optimizations on a bunch of nested templated types is worst of both worlds: it’s amazingly awkward _and_ slow. CTFE is almost fine for stright-forward manipulations.

Notation could be improved by using the same expression template idea but with polymorphic types at CTFE.

Another thing is partial specialization:

alias squareMod = bluePrint.assume({ “b” : 2 }).instantiate;

Now :

squareMod(a,c); // should be faster the elaborate algorithm

I think the general idea is a good approach, and it seems that ultimately we're just reinventing expression DSLs. Overloading built-in operators works up to a point, and then you really want to just use a string DSL, parse that in CTFE and use mixin to codegen.

That frees you from the spaghetti template expansions in expression templates, and also frees you from being limited by built-in operators, precedence, and syntax.

Staged aproach has the benefit of composing pieces together + partial specialization. In a sense “parse the DSL” could do the same if it splits AST and codegen phases.

Reply via email to