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