On Monday, 4 January 2021 at 17:48:50 UTC, ag0aep6g wrote:
> I think you're hitting the nail on the head here regarding the confusion. Such a rewrite makes intuitive sense, and it would be nice, but it doesn't happen.

So, does that mean that you agree that having better unification would be a worthwhile item to have on a wish list for 2021? So, if somebody want to do a full implementation that performs well, then it would be an interesting option?


Quite frankly, it is much better to just say "oh, this is a deficiency in the implementation" than to say that the language spec is fubar...

Also, the whole idea of writing the language spec to match the implementation is not a good approach.

I think D could become competitive if the existing feature set is streamlined and polished.

On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote:
> On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
>> [snip]
>>
> [snip[
> Regardless, the DIP likely could have been improved by mentioning its inclusion in C++ 11 (and perhaps focused a bit less on implementation).

Yes.

On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote:
>> The only D compiler that uses excess precision is DMD and only if -O flag is passed. The same example compiled with GDC uses write-read codes. LDC uses SSE codes.
>
> DMD still supports baseline 32 bit Windows that does not have XMM registers.

It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform.
Accidental correctness of say, C integer promotion, doesn't break on another system - it's OK ; it's a different ilk.

What about this plan?
- use SSE all the time in DMD
- drop real :)

On Tuesday, 5 January 2021 at 13:30:50 UTC, Guillaume Piolat wrote:
> On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote:
>>> The only D compiler that uses excess precision is DMD and only if -O flag is passed. The same example compiled with GDC uses write-read codes. LDC uses SSE codes.
>>
>> DMD still supports baseline 32 bit Windows that does not have XMM registers.
>
> It would be nice if no excess precision was ever used.

Fun fact: in AIFF files the samplingrate is stored as a 80 bit IEEE Standard 754 floating point. ;)

On Monday, 4 January 2021 at 22:55:28 UTC, Ola Fosheim Grøstad wrote:
> It is a name, e.g.:
>
> alias BarInt = Bar!int;
>
>
> "BarInt", "Bar!int" and "Foo!int" are all names, or labels, if you wish. And they all refer to the same object: the nominal type. Which you can test easily by using "is(BarInt==Foo!int)".

Bar!int is not a name. It's declaration. Bar is the name.
https://github.com/dlang/dmd/blob/master/src/dmd/dtemplate.d#L5754

Labels are myLabel: and are used with goto, break, continue.

Objects are class instances.

On Monday, 4 January 2021 at 23:08:31 UTC, Ola Fosheim Grøstad wrote:
> If the terminology is difficult, <...>

The main problem here is that you use words/definitions interchangeably that refer to similar concepts but are different. As if they are the same. They are not! I got the concept from the first post and I believe most here got it too. What we have trouble here is getting it from abstract realm to reality. And reality demands it to be specific.

> <other names> and type "struct _ {}" <...> should be interchangeable with no semantic impact.

What you want is to reference template thingy by name and assign it to thing so when you use the thing it should be interchangeable with template thingy and should be semantically equivalent. So what is a thing? From your posts its either/or:
1. identifier
2. declaration.

And from your posts the template thingy is either/or:
1. template instantiation
2. template definition

Since you cant get specific we will talk about all 4 possibilities. For a template declaration of myStruct lets see how we can go about creating an alias to it.

struct myStruct(T) {}

For assigning template instantiation to a identifier(1,1) its simple.
alias myS11 = myStruct!int;

For assigning template definition to a identifier(1,2) you write like this
alias myS12 = myStruct;

For assigning template instantiation to a declaration(2,1) well you cant. The language does not permit that.

For assigning template definition to a declaration(2,2). You cant do that too.

And in practice it looks like this
[code]
struct myStruct(T) {}
void f(T)(myStruct!T x) {}

void main()
{
    alias myS11 = myStruct!int;
    alias myS12 = myStruct;
   	
    myStruct!int x;
    f(x);

    myS11 x11;
    f(x11);

    myS12!int x12;
    f(x12);	
}
[/code]

Now there are also function templates but I will leave it as homework assignment. So the million dollar question is. What do you want to do with alias assignment to declaration that you cant do by assignment to identifier?


> Drop ad hominem. Argue the case.

Ad hominem is when you use insult INSTEAD of argument. A detail that most people miss. Also how "i'm like you" is an insult?

On Tuesday, 5 January 2021 at 15:04:34 UTC, welkam wrote:
> Also how "i'm like you" is an insult?

I don't think I should reply to this…

On 05.01.21 11:44, Ola Fosheim Grøstad wrote:
> So, does that mean that you agree that having better unification would be a worthwhile item to have on a wish list for 2021? So, if somebody want to do a full implementation that performs well, then it would be an interesting option?

Sure. I've said in my first post in this thread that "issue 1807 is well worth fixing/implementing".

> Quite frankly, it is much better to just say "oh, this is a deficiency in the implementation" than to say that the language spec is fubar...

It's not either or. The spec on IFTI is lacking. That's true whether we we call issue 1807 a bug or an enhancement.

I don't think it's a productive use of our time, but if you'd like to argue semantics, here's why I don't consider issue 1807 a "bug":

(PS: This turned out longer than planned. Please feel free to ignore.)

A program has a bug when it doesn't behave as intended by its author. I think that's a pretty permissive definition of bug. So, DMD has a bug when it doesn't behave as Walter intended when he wrote or accepted the code.

I see no evidence that IFTI's type deduction was ever intended to behave as requested in issue 1807. The spec doesn't say it should work. Walter has not come forward to say that he made a mistake in the implementation.

I do see evidence that the existing deduction works as intended: Walter has called issue 1807 a "good idea for an enhancement request"[2], i.e. not a bug.

Maybe most importantly, the existing behavior just feels like the kind of thing Walter does. Start with trivial deduction, allowing this:

    void f(T)(T p) {}
    int x;
    f(x);

Then also allow derived types (e.g. pointers), because all the needed info is readily available in the type (DMD can get `int` from the type `int*`):

    void f(T)(T* p) {}
    int* x;
    f(x);

Then realize that types created from templates also keep the needed info around for name mangling (DMD can get `S` and `int` from the type `S!int`). Use that to allow:

    struct S(T) {}
    void f(S!T p) {}
    S!int x;
    f(x);

Done. Incremental improvements lead to a system that works pretty well a lot of the time. That's Walter's signature, isn't it?

> Also, the whole idea of writing the language spec to match the implementation is not a good approach.

I don't disagree. But we have to work with what we got. The implementation exists. The spec doesn't.

Documenting the existing system has merit, even when you or someone else eventually finds the time and motivation to design a better one.


[1] https://dlang.org/spec/template.html#function-templates
[2] https://issues.dlang.org/show_bug.cgi?id=1807#c1

On Tuesday, 5 January 2021 at 17:13:01 UTC, ag0aep6g wrote:
> Sure. I've said in my first post in this thread that "issue 1807 is well worth fixing/implementing".

Ok, if we have a majority for this, then all is good.

> A program has a bug when it doesn't behave as intended by its author. I think that's a pretty permissive definition of bug. So, DMD has a bug when it doesn't behave as Walter intended when he wrote or accepted the code.

Ok, I can't argue if that is the definition.

My main concern is that we need to attract more people with a strong comp.sci. background because as a language grow it becomes more tricky to improve and the most difficult topics are the ones that remain unresolved (like we see with @live, shared and GC).

I agree that there are more important topics than streamlining parametric types. Like shared and memory management. But it is still important to have an idea of which areas are worth picking up, if someone comes along with an interest in writing solvers, then this could be something he/she could tinker with.

> should work. Walter has not come forward to say that he made a mistake in the implementation.

Ok, but that is not important. What is important is that if someone comes along with an interest in this area, then we can encourage them to work on it.


> Done. Incremental improvements lead to a system that works pretty well a lot of the time. That's Walter's signature, isn't it?


That happens in many compiler development cycles. Of course, D has also added a lot of features... perhaps at the expense of bringing what is to perfection.

> I don't disagree. But we have to work with what we got. The implementation exists. The spec doesn't.

It probably would be a good idea to focus on one subsystem at a time. Refactor, document, make a list of priority improvements for that subsystem, and then improve/reimplement, document, then move on to the next subsystem.

If memory management is in the center now, then that is great, but then maybe the next cycle could take another look at the type system as a whole.

On Tuesday, 5 January 2021 at 18:06:32 UTC, Ola Fosheim Grøstad wrote:
> My main concern is that we need to attract more people with a strong comp.sci. background because as a language grow it becomes more tricky to improve and the most difficult topics are the ones that remain unresolved (like we see with @live, shared and GC).

I don't have that background myself, so I don't think I can provide any insight here.

[...]
> It probably would be a good idea to focus on one subsystem at a time. Refactor, document, make a list of priority improvements for that subsystem, and then improve/reimplement, document, then move on to the next subsystem.
>
> If memory management is in the center now, then that is great, but then maybe the next cycle could take another look at the type system as a whole.

I'm afraid I don't have anything profound to contribute here either. I have no idea how to manage a group of volunteers (including Walter).

On Tuesday, 5 January 2021 at 18:48:06 UTC, ag0aep6g wrote:
> On Tuesday, 5 January 2021 at 18:06:32 UTC, Ola Fosheim Grøstad wrote:
>> My main concern is that we need to attract more people with a strong comp.sci. background because as a language grow it becomes more tricky to improve and the most difficult topics are the ones that remain unresolved (like we see with @live, shared and GC).
>
> I don't have that background myself, so I don't think I can provide any insight here.

Well, what I mean is that it is not so bad if D is perceived as an "enthusiast language", then you don't expect a flawless implementation. If the language spec outline something that is "beautiful" (also in a theoretical sense) and show where the implementation needs some love then people can contribute in areas they are interested in. If the spec is so-so, then it will be a revolving door...


>> It probably would be a good idea to focus on one subsystem at a time. Refactor, document, make a list of priority improvements for that subsystem, and then improve/reimplement, document, then move on to the next subsystem.
>>
>> If memory management is in the center now, then that is great, but then maybe the next cycle could take another look at the type system as a whole.
>
> I'm afraid I don't have anything profound to contribute here either. I have no idea how to manage a group of volunteers (including Walter).


Most people will shy away from the difficult, tedious or boring bits, so by keeping focus on one subsystem at a time, one could hope that the difficult/tedious/boring bits receive more attention... (Nothing specific for D, just human behaviour.)