On Wednesday, 7 October 2020 at 11:58:35 UTC, claptrap wrote:
> Lets reverse the roles, say TF were invented first, and somebody was arguing for templates to be added now. The TP version would be a couple of stdlib calls and the template version a whole page.

Templates actually enable all kinds of new things.

A type function cannot actually generate any new code nor create new types. Those are explicit limitations in the design right now, because by keeping them so strict it enables some optimizations that are... at best tricky with templates (many attempts to optimize templates end up causing compiler bug errors or, perhaps worse yet, random linker errors).

So supposed we lived in a world with only TF. You can make type lists and return basic type constants based on limited reflection over type (note that TFs will probably *not* support advanced `is` expression pattern matching as it is right now!)

Then someone comes along and says let's add templates. Templates can do everything a type function can do AND you can generate new code based on that information! No more awkwardly returning string literals and mixing them in at the usage point, the compiler will generate it all directly!

Oh there'd probably be pushback, I'd probably be arguing "but we can already mixin!" myself :) (though mixin sucks for name generation, you have to use __LINE__ or cookie string hacks, whereas templates automatically get unique names!)

But it'd also be a compelling new feature.

That's why I'd be a bit more excited about the type functions if they prove capable of doing things we can't really do right now, like transform function argument lists through tuple manipulation. That'd be a cool application of the same general principle of reordering alias[] entities.

On Wednesday, 7 October 2020 at 12:37:48 UTC, Stefan Koch wrote:
> On Wednesday, 7 October 2020 at 12:30:15 UTC, Andrei Alexandrescu wrote:
>> Incumbency is a huge matter in programming language design. Of course I would not propose another way of doing the same thing.
>
> Perhaps you can say this in different words?

Basically we just prefer to work with what we have before adding new stuff to the language.

So whatever features get added first have an automatic advantage in any comparison just because they are already there.

On Wednesday, 7 October 2020 at 12:37:48 UTC, Stefan Koch wrote:
> On Wednesday, 7 October 2020 at 12:30:15 UTC, Andrei Alexandrescu wrote:
>> On 10/7/20 7:58 AM, claptrap wrote:
>>> Lets reverse the roles, say TF were invented first, and somebody was arguing for templates to be added now. The TP version would be a couple of stdlib calls and the template version a whole page.
>>
>> Incumbency is a huge matter in programming language design. Of course I would not propose another way of doing the same thing.
>
> I just looked up Incumbency, but the German translation was 'Time someone has been in office' ...
> I am not seeing how these things relate.
> Perhaps you can say this in different words?

incumbent = the established order.

It's usually used in the context of a politician in office who defending his position rather than challenging for it. IE. Trump is the incumbent, Biden is the challenger.

On Wednesday, 7 October 2020 at 12:54:09 UTC, Adam D. Ruppe wrote:
> That's why I'd be a bit more excited about the type functions if they prove capable of doing things we can't really do right now, like transform function argument lists through tuple manipulation. That'd be a cool application of the same general principle of reordering alias[] entities.

I think you should just add type variables and improve on other mechanisms until you have those capabilities, the you restrict the usage of type variables to what Stefan can implement so that this feature gets a release date. After that it can be extended one step at the time, maybe even to runtime.

The whole has to be specced out before release, but the initial release can be constrained to a subset.

On 07.10.20 04:33, Andrei Alexandrescu wrote:
> On 10/6/20 9:07 PM, claptrap wrote:
>> On Tuesday, 6 October 2020 at 23:39:24 UTC, H. S. Teoh wrote:
>>> On Tue, Oct 06, 2020 at 11:16:47PM +0000, claptrap via Digitalmars-d wrote: [...]
>>>>
>>> I would write it like this:
>>>
>>>     int[] vals = [4,7,28,23,585,73,12];
>>>
>>>     int[] getMultiplesOf(int i)
>>>     {
>>>         return vals.filter!(v => (v % i) == 0).array;
>>>     }
>>>
>>> One line vs. 4, even more concise. ;-)
>>
>> The point is to show language not library.
> 
> That's a made-up restriction, and it's odd that it is being discussed here as a virtue.
> ...

I agree. This is a bad way to market a new language feature. However, I don't think "library over language" is necessarily a good justification for an inefficient implementation of core language features.

> Beginners are attracted to large languages that have everything built in.

Isn't it rather that beginners can't tell the difference?

> A good language is focused on general primitives that allow writing a great deal in libraries.
> 
> 

Certainly, but a good language does not require you to write the same functionality multiple times.

On 07.10.20 10:25, Patrick Schluter wrote:
>>
>> I'm honestly losing the will to live here.
> 
> Thank you. I was myself wondering why this feature was encountering such an amount of resistance, especially from the top tier of the language specialists.

Fear of losing the edge? :o)

On 07.10.20 14:32, claptrap wrote:
> On Wednesday, 7 October 2020 at 11:55:00 UTC, Paolo Invernizzi wrote:
>> On Wednesday, 7 October 2020 at 11:19:24 UTC, claptrap wrote:
>>> On Wednesday, 7 October 2020 at 09:04:59 UTC, Ola Fosheim Grøstad wrote:
>>>> On Wednesday, 7 October 2020 at 08:49:21 UTC, Patrick Schluter wrote:
>>>>> On Wednesday, 7 October 2020 at 02:33:21 UTC, Andrei Alexandrescu wrote:
>>>>
>>>>
>>>> Right again. Funtional programming is only pleasant in a dedicated FP language, and even then you need to memorize a large set of library constructs to be productive.
>>>
>>> How many pure funtional languages are in the tiobe top 10? None or maybe 1 im not sure. Theres a reason for that i reckon.
>>
>> We are using a pure functional language for web frontend development, and it's a joy ...
> 
> Maybe they're great in specific circumstances? I dont know what the reason is but if FP was so intuitive then you'd expect it'd be the norm, or at least on a par, or even in the same ballpark as imperative?

This particular discussion is not about functional vs imperative at all, it is about awkward vs decent.

On Wednesday, 7 October 2020 at 12:56:42 UTC, Adam D. Ruppe wrote:
> On Wednesday, 7 October 2020 at 12:37:48 UTC, Stefan Koch wrote:
>> On Wednesday, 7 October 2020 at 12:30:15 UTC, Andrei Alexandrescu wrote:
>>> Incumbency is a huge matter in programming language design. Of course I would not propose another way of doing the same thing.
>>
>> Perhaps you can say this in different words?
>
> Basically we just prefer to work with what we have before adding new stuff to the language.
>
> So whatever features get added first have an automatic advantage in any comparison just because they are already there.

I agree.

And existing features got added after already having their fundamental ideas, advantages, and deficiencies scrutinized.

The fact that we have meta-programming in the form we have, is not by chance. It is a super strong and capable design.
I am biased, but I would say "state of the art".

If we boil down the Type Function proposal to its fundamental idea, advantages, and deficiencies. What Do we get?

Fundamental idea:
Language level reification of a set of types, making a set of types mutable to enable imperative programming style, for what is essentially only changing that set of types.
But at that, only in the context of a special kind of CTFE-like function.
Other than mutating a set of types, This function cant do anything that cant already be achieved rather simply with existing language features. As has been demonstrated a number of times in this thread.

Advantage:
Mutating a set of types in an imperative style. Something that is already quite simple, and requires virtually the same, or even less code in practice when written with existing language features.

Disadvantage: A new feature people will have to learn and understand, document, maintain, bugfix.
No actual substantial future gain.

Is this wrong?
Or where is that striking idea nobody can spot, that we just must enable with language level complexity? If the best answer is "Imperative type set manipulation"… Geeezzz…

I would love to see an example, of the epitome of what goodness TypeFunctions could unlock. What I've seen so far is basically nothing, at the cost of far more than nothing. No Deal.

/Daniel K

On 10/7/20 12:17 AM, H. S. Teoh wrote:
> On Tue, Oct 06, 2020 at 08:47:33PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 10/6/2020 11:09 AM, Adam D. Ruppe wrote:
>>> The Phobos implementation started life with a very simple
>>> implementation too. It became what it is because it *had to*,
>>> specifically for performance reasons.
>>
>> Professional C Standard library implementations tend to be hideous
>> code to perform objectively simple operations. The reason is speed is
>> so desirable in foundational code that it drives out all other
>> considerations. (memcpy() is a standout example.)
> 
> A little tangential aside: one time as a little coffee break challenge,
> I decided to see how D compares to GNU wc in terms of the speed of
> counting lines in a text file.  The core of wc, of course, is in memchr
> -- because it's scanning for newline characters in a buffer.  In the
> course of ferreting out what made wc so fast, I studied how GNU libc
> implemented memchr.  Basically, in order to speed up scanning large
> buffers, it uses a series of fancy bit operations on 64-bit words in
> order to scan 8 bytes at a time, I suppose the goal being to achieve
> close to 8x speedup, and also to reduce the number of branches per
> iteration to capitalize on the CPU's pipeline.

memchr is also the secret sauce to how iopipe was able to beat Phobos byLine and getline.

I would like to go back to it at some point and see if it can be improved.

I know that part of the difference would be due to the opaque function call (this cannot be inlined), though perhaps memchr is an intrinsic?

-Steve

On Wednesday, 7 October 2020 at 14:01:51 UTC, Daniel K wrote:
> The fact that we have meta-programming in the form we have, is not by chance. It is a super strong and capable design.
> I am biased, but I would say "state of the art".

State of the art requires rewrite-capabilities like Lisp, Pure and many other languages have.

C++ chose simple templating, but got burned as users abused it to do more. That aspect of C++ was an unintended design flaw!

D chose the same course, but through a deliberate design. So they could have a more readable syntax (the semantics differ too, but both have advantages/disadvantages).