rvalue types

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Mar 13 19:14:56 UTC 2018


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.





More information about the Digitalmars-d mailing list