Funny...

<https://twitter.com/snoyberg/status/882255351382462464>

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"

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.

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.

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

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

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

On Thursday, 6 July 2017 at 00:22:04 UTC, H. S. Teoh wrote:
>
> IOW, the parameter should be a "some other time" parameter. :-D
>
>
> T

There was a previous thread [1] about a language that had a few different options for how to handle compile time or run time or both or whatever.

[1] http://forum.dlang.org/thread/ne3265$uef$1@digitalmars.com