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