www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's wrong with D ? this bug remains unfixed since 12 years

reply Basile B. <b2.temp gmx.com> writes:
Context:

https://issues.dlang.org/show_bug.cgi?id=10228
https://issues.dlang.org/show_bug.cgi?id=9024

You might have seen a recent post of mine, initially designed to 
speak about IFTI and tuples, where I explain that I have 
developed something similar to IFTI.

Turns out that, until yesterday, they failed too. Fixed them 
quickly:

https://gitlab.com/styx-lang/styx/-/commit/b026f923cf7619b795557e79ece969deaffcc326

I have a theory that is "we all make the same mistakes" (i.e when 
it's time to implement, we the human beings). It's possible that 
actually for those two bugs, D IFTI works but after IFTI, the 
wrong scope is used, or-and that `resolve` is canceled too early.

I dont see how a mediocre language like styx can handle that 
while D still cant.

A bon entendeur and sorry for the provocation ;)
May 30
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 5/30/24 15:10, Basile B. wrote:

 Context:
 
 https://issues.dlang.org/show_bug.cgi?id=10228
 https://issues.dlang.org/show_bug.cgi?id=9024
 
 You might have seen a recent post of mine, initially designed to speak 
 about IFTI and tuples, where I explain that I have developed something 
 similar to IFTI.
 
 Turns out that, until yesterday, they failed too. Fixed them quickly:
 
 https://gitlab.com/styx-lang/styx/-/commit/b026f923cf7619b795557e79ece969deaffcc326
 
 I have a theory that is "we all make the same mistakes" (i.e when it's 
 time to implement, we the human beings).


Counterpoint: Those examples work with my frontend.
(https://github.com/tgehr/d-compiler/)


 It's possible that actually for 
 those two bugs, D IFTI works but after IFTI, the wrong scope is used, 
 or-and that `resolve` is canceled too early.
 
 I dont see how a mediocre language like styx can handle that while D 
 still cant.
 ...


I guess different priorities and different allocation of focus and 
expertise. The desire to make template matching fast might have led to 
some shortcuts being taken. Have not actually worked with that part of 
the compiler so far though.


 A bon entendeur and sorry for the provocation ;)
 ...
May 30
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 30 May 2024 at 13:10:54 UTC, Basile B. wrote:

 I have a theory that is "we all make the same mistakes" (i.e 
 when it's time to implement, we the human beings). It's 
 possible that actually for those two bugs, D IFTI works but 
 after IFTI, the wrong scope is used, or-and that `resolve` is 
 canceled too early.

 I dont see how a mediocre language like styx can handle that 
 while D still cant.


D's IFTI implementation is really, really bad. If you stray even 
slightly from the "happy path" of conventional, idiomatic code, 
it completely falls apart. Here's a list of just the bugs that I 
*personally* have found and reported in D's IFTI:

- https://issues.dlang.org/show_bug.cgi?id=22903
- https://issues.dlang.org/show_bug.cgi?id=22111
- https://issues.dlang.org/show_bug.cgi?id=23292
- https://issues.dlang.org/show_bug.cgi?id=23645
- https://issues.dlang.org/show_bug.cgi?id=23644

I would not be surprised if a ground-up rewrite of the entire 
IFTI implementation was necessary to fix all of these issues.
May 30
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 30 May 2024 at 18:09:34 UTC, Paul Backus wrote:

 On Thursday, 30 May 2024 at 13:10:54 UTC, Basile B. wrote:

 I have a theory that is "we all make the same mistakes" (i.e 
 when it's time to implement, we the human beings). It's 
 possible that actually for those two bugs, D IFTI works but 
 after IFTI, the wrong scope is used, or-and that `resolve` is 
 canceled too early.

 I dont see how a mediocre language like styx can handle that 
 while D still cant.


 D's IFTI implementation is really, really bad. If you stray 
 even slightly from the "happy path" of conventional, idiomatic 
 code, it completely falls apart. Here's a list of just the bugs 
 that I *personally* have found and reported in D's IFTI:

 - https://issues.dlang.org/show_bug.cgi?id=22903
 - https://issues.dlang.org/show_bug.cgi?id=22111
 - https://issues.dlang.org/show_bug.cgi?id=23292
 - https://issues.dlang.org/show_bug.cgi?id=23645
 - https://issues.dlang.org/show_bug.cgi?id=23644

 I would not be surprised if a ground-up rewrite of the entire 
 IFTI implementation was necessary to fix all of these issues.


These issues are very specific to the D type system, for example 
I see problem related to type qualifiers.

For the two old issues I mentioned the simple algorithm should 
work. You try to see how the AST of the parameter type and the 
argument type match. You decompose them in paralell. If at some 
point the decomposition of the parameter ends up on an identifier 
and that the identifier matches to a template parameter then it's 
likely that the ident matches to what the paralell decomposition 
of the argument type is at. Simple stupid. As said previously I 
think that the two bugs are not related to IFTI but to the scope 
used to run the typesem... hard to explain it better.

In a world where it would be allowed to bet on software bugs I'd 
bet it's not a IFTI problem and that it's a scope problem. If you 
try to find something that doesn't exist in a scope you wont find 
it.

Anyway 12 years ;)
May 30
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 5/30/24 20:09, Paul Backus wrote:

 Here's a list of just the bugs that I *personally* have found and 
 reported in D's IFTI:
 
 - https://issues.dlang.org/show_bug.cgi?id=22903


Not a bug (no IFTI is involved).


 - https://issues.dlang.org/show_bug.cgi?id=22111


I agree this should ideally work, but I am not sure I would call it a 
bug per se.


 - https://issues.dlang.org/show_bug.cgi?id=23292


Seems my frontend gets this one wrong too, though technically I don't 
think the spec implies that this should work.


 - https://issues.dlang.org/show_bug.cgi?id=23645


https://dlang.org/spec/template.html#function-templates

 If a template declares exactly one member, and that member is a function with
the same name as the template, it is a function template declaration. 


https://dlang.org/spec/template.html#ifti

 Function templates can be implicitly instantiated


So I guess the spec needs updating too here. It contradicts itself:
https://dlang.org/spec/template.html#implicit_template_properties

However, I do think it is not obvious from the spec that IFTI should 
even work on function template templates. (Though it makes sense that it 
would.)


 - https://issues.dlang.org/show_bug.cgi?id=23644


Here I am again not sure whether there was ever any intention for this 
to work, but it should be fixed in any case.

Overall, I think this is an issue of incomplete spec as much as one of 
implementation quality.
May 31
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 31 May 2024 at 07:40:09 UTC, Timon Gehr wrote:

 On 5/30/24 20:09, Paul Backus wrote:

 Here's a list of just the bugs that I *personally* have found 
 and reported in D's IFTI:
 
 - https://issues.dlang.org/show_bug.cgi?id=22903


 Not a bug (no IFTI is involved).


In that case, the spec's section on lambda parameter type 
inference [1] should be updated to clarify this.

[1] 
https://dlang.org/spec/expression.html#lambda-parameter-inference


 - https://issues.dlang.org/show_bug.cgi?id=22111


 I agree this should ideally work, but I am not sure I would 
 call it a bug per se.


If IFTI was unable to match the type `int[]` with the pattern 
`T[]`, nobody would doubt that was a bug. How is this different?


 - https://issues.dlang.org/show_bug.cgi?id=23292


 Seems my frontend gets this one wrong too, though technically I 
 don't think the spec implies that this should work.


I think the spec's section on name lookup [2] implies that this 
should work. There is nothing in the spec about IFTI or templates 
that implies any exception is made to the normal lookup rules in 
this case.

[2] https://dlang.org/spec/module.html#name_lookup


 - https://issues.dlang.org/show_bug.cgi?id=23645




[...]

 However, I do think it is not obvious from the spec that IFTI 
 should even work on function template templates. (Though it 
 makes sense that it would.)


 - https://issues.dlang.org/show_bug.cgi?id=23644


 Here I am again not sure whether there was ever any intention 
 for this to work, but it should be fixed in any case.


Regardless of whether these are intended to work, I'd say the 
order-dependent behavior is a bug. But I do think it would be 
nicer to make them work in all cases than fail in all cases.
May 31
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 5/31/24 14:01, Paul Backus wrote:

 On Friday, 31 May 2024 at 07:40:09 UTC, Timon Gehr wrote:

 On 5/30/24 20:09, Paul Backus wrote:

 Here's a list of just the bugs that I *personally* have found and 
 reported in D's IFTI:

 - https://issues.dlang.org/show_bug.cgi?id=22903


 Not a bug (no IFTI is involved).


 
 In that case, the spec's section on lambda parameter type inference [1] 
 should be updated to clarify this.
 
 [1] https://dlang.org/spec/expression.html#lambda-parameter-inference
 ...


Probably.


 - https://issues.dlang.org/show_bug.cgi?id=22111


 I agree this should ideally work, but I am not sure I would call it a 
 bug per se.


 
 If IFTI was unable to match the type `int[]` with the pattern `T[]`, 
 nobody would doubt that was a bug. How is this different?
 ...


The pattern `T[]` is injective. The pattern `T.property` is not injective.


 - https://issues.dlang.org/show_bug.cgi?id=23292


 Seems my frontend gets this one wrong too, though technically I don't 
 think the spec implies that this should work.


 
 I think the spec's section on name lookup [2] implies that this should 
 work. There is nothing in the spec about IFTI or templates that implies 
 any exception is made to the normal lookup rules in this case.
 ...


What I mean is the spec says IFTI only works for function templates. 
Technically if you have an import in the template body there is no IFTI 
because it is not a function template.

Currently it seems IFTI only looks at the eponymous member's signature 
during IFTI. It does not look at any of the other declarations. It is 
also hard to analyze those declarations, because the template parameters 
are not yet known during IFTI.

It can also not work in the general case, because which module is 
imported may depend on template parameters. So now you are in a 
situation where you have to partially analyze the template body during 
instantiation.

I think if you allow arbitrary partial analysis, IFTI becomes 
undecidable. Therefore I think you would have to more clearly state what 
you expect to see in the specification rather than just assume if it 
does not work it is a bug.

I.e., I think as long as the spec does not explicitly state "imports of 
this or this shape are analyzed during IFTI", you cannot really say the 
implementation is "buggy", it just does not work the way you'd like it to.


 [2] https://dlang.org/spec/module.html#name_lookup
 

 - https://issues.dlang.org/show_bug.cgi?id=23645




 [...]

 However, I do think it is not obvious from the spec that IFTI should 
 even work on function template templates. (Though it makes sense that 
 it would.)


 - https://issues.dlang.org/show_bug.cgi?id=23644


 Here I am again not sure whether there was ever any intention for this 
 to work, but it should be fixed in any case.


 
 Regardless of whether these are intended to work, I'd say the 
 order-dependent behavior is a bug. But I do think it would be nicer to 
 make them work in all cases than fail in all cases.


AFAICT, there is no specification for this particular interaction, but 
in `is` expressions the pattern has to come first too.

Anyway, this has at least some component of language design in it, it's 
not just bug fixing.
May 31
prev sibling parent reply Elias (0xEAB) <desisma heidel.beer> writes:
What’s wrong with D you ask? :P
Well, everyone keeps using abbr.s and specialist terms from 
compiler engineering to the extent where to avg. usr.’s supposed 
to undrstnd ’em as well.
That’s also what’s wrong with error messages of D compilers in 
particular.
/s
May 31
parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 31 May 2024 at 21:39:54 UTC, Elias (0xEAB) wrote:

 What’s wrong with D you ask? :P
 Well, everyone keeps using abbr.s and specialist terms from 
 compiler engineering to the extent where to avg. usr.’s 
 supposed to undrstnd ’em as well.
 That’s also what’s wrong with error messages of D compilers in 
 particular.
 /s


You `have` my `agreement`. It is a very `important` thing to get.
May 31
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 31 May 2024 at 22:39:28 UTC, Basile B. wrote:

 You `have` my `agreement`. It is a very `important` thing to 
 get.


I recently learned that SQL, one of the worst languages 
programmers are stuck with, was intentionally designed in that 
way to be accessible for non-specialists. We should not repeat 
that mistake. Let D remain a powerful tool for professionals 
designed by professionals.
Jun 01
parent Basile B. <b2.temp gmc.com> writes:
On Saturday, 1 June 2024 at 07:12:19 UTC, Max Samukha wrote:

 On Friday, 31 May 2024 at 22:39:28 UTC, Basile B. wrote:

 You `have` my `agreement`. It is a very `important` thing to 
 get.


 I recently learned that SQL, one of the worst languages 
 programmers are stuck with, was intentionally designed in that 
 way to be accessible for non-specialists. We should not repeat 
 that mistake. Let D remain a powerful tool for professionals 
 designed by professionals.


No off-topic or extrapolation attempts please. I'm sorry if the 
topic lead to the idea that it was possible but essentially 
everything unrelated to IFTI is considered off-topic.
Jun 01