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
