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.
