OT: Go go gadget templates

Nicholas Wilson via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 5 18:01:56 PDT 2017


On Thursday, 6 July 2017 at 00:22:04 UTC, H. S. Teoh wrote:
> On Wed, Jul 05, 2017 at 05:04:40PM -0700, Ali Çehreli via 
> Digitalmars-d wrote:
>> On 07/05/2017 04:25 PM, Luís Marques wrote:
>> > Funny...
>> > 
>> > <https://twitter.com/snoyberg/status/882255351382462464>
>> 
>> Creative! However, I'm offended that other people never 
>> appreciate D's syntax. Why did they go (argh!) for C++ and 
>> Java template syntax? :/
>> 
>> Speaking of which, I've just experimented with triple function 
>> parameter lists: for run time, for compile time, and for ... 
>> some other time...
>> 
>> Note how it allows foo() and bar() function template templates 
>> to
>> share template template arguments (long and uint below):
>> 
>>     foo❗⎛long⎞!"hello"(42);
>>     bar❗⎝uint⎠!"world"(43);
>> 
>> Ali
>> "this is a joke"
>
> You may have intended it as a joke, but lately I've been 
> thinking about algorithms with parameters that really shouldn't 
> be fixed to runtime or compile-time, but rather this decision 
> should be postponed till later. In other words, a kind of "some 
> other time" parameter.  In particular, from a higher-level POV, 
> the decision about whether a parameter is baked in at 
> compile-time or left open till runtime really ought to be 
> decided by the compiler based on various factors.
>
> If you have a library function f that takes two parameters, x 
> and y, but your program only ever calls it with x=10, say, then 
> it benefits the executable to have x as a compile-time 
> parameter -- you save on the cost of passing an extra parameter 
> that's going to have the same value anyway.  OTOH, as the 
> library author, you don't know whether your users will always 
> call f with a compile-time known x, so you could either make 
> that decision for your users, which then leaves them stranded 
> if you decided x is better off as a compile-time parameter but 
> they need to pass a runtime parameter to it; or you could 
> decide to make it a runtime parameter, but then lose out on the 
> use cases where x is already known at compile-time.
>

What you describe is profile guided optimisation.

> Now consider the case if f has two runtime parameters, and the 
> user writes code like this:
>
> 	auto z = f(1, 2);
>
> As part of the compiler's optimization pass, the compiler 
> notices that since both parameters are compile-time constants, 
> it could simply evaluate f in CTFE and fold its return value 
> into z, completely, thus effectively making the decision 
> turning what was declared as runtime parameters into 
> compile-time parameters.
>

Use enum or just use ldc2 -O3

> On the flip side, if f is declared to have x and y both 
> compile-time parameters, then you have the problem of template 
> bloat if f is called with a wide variety of arguments.
>
> And in the "in-between" cases, sometimes f is called with 
> arguments known at compile-time, sometimes with arguments only 
> known at runtime.
>
> Arguably, it should be part of the compiler's optimizer that 
> decides whether it's "worth" turning some runtime parameters of 
> f into compile-time arguments, or, if it deems template bloat 
> to be a problem, turning some currently-compile-time parameters 
> to be runtime parameters instead. Ultimately, the library 
> author shouldn't be forced to decide either way, unless it's 
> part of the API design to force certain parameters to be 
> compile-time or runtime.  At least there should be the 
> possibility of telling the compiler "this parameter could be 
> either compile-time or runtime, you decide later when user code 
> calls this function".
>
> IOW, the parameter should be a "some other time" parameter. :-D
>
>
> T



More information about the Digitalmars-d mailing list