On 6/10/2022 12:52 PM, max haughton wrote:
> No it really is bad. Some newer areas are ok but the quality of the code is overall just bad, relies on enormous amounts of mutability, doesn't have a proper opinion about how to resolve symbols (it only has 3 passes), tries to make decision before properly analyzing the problem etc.

RE the symbol lookup. Before you joined us, the symbol table lookup was simple and straightforward. But everyone complained that it was "unintuitive". Lookup in scopes, classes, and imports, all worked exactly the same way. I spend countless emails explaining how lookup all worked the same way. Not one person said they understood it, it was always "it makes no sense".

So, it was changed to a 2 pass lookup. Everyone liked that, and said it was intuitive. The 3rd pass was to enable legacy compatibility. So there you have it, 3 passes.

It's a classic case of something that is simple and straightforward from a math point of view is hopelessly unintuitive for humans.

As for mutability, this stems from two things:

1. using the Visitor pattern, which precludes using const and is excessively complex (in my opinion). But as you know, Dennis and I have been gradually replacing it with nested functions.

2. In order to support forward references, the semantic routines are lazy to a large extent. Lazy means that when information is asked for, often it needs to be computed if it hasn't been yet.


> The compiler is mostly reasonable semantically because D is a conventional language, but several key parts of the logic are either extremely old messy bits of code that basically cannot be easily changed or types with a very sloppy heritage that lead to an explosion of edge cases all over the place: Array, Struct, and Int32 are all considered to be the same type of thing according to the enum at the heart of the class that represents types,

??? isTypeArray and isTypeStruct are distinct types

> it's ad-hoc "eh just ship it code" that almost no one can be bothered to fix because they've either been scared off from working on the compiler because of aforementioned warts or because they've tried to divide and conquer the cleanup efforts and been told no.

Doing cleanup is hard, though you've seen many PRs from me that move in that direction.

> Probably 40% of the bug fixes of the kind you posit are *because* of the frontend being unreliable.

I disagree. It's mostly because of unexpected interaction between features, or cases nobody thought of.

BTW, I hate the front end inliner, and am trying to replace it with a far simpler backend one. Success in that means eliminating nearly 3000 lines of ugly code.

But I'm having some problems with the test suite, as it is failing in ways I cannot reproduce locally. Any help in getting closer to what causes the failures would be most helpful:

https://github.com/dlang/dmd/pull/14194

The optimizer and backend date back to the 1980s, and were written in the C style fashionable at the time. I've been slowly refactoring it to be better, in particular use of D arrays, and the CodeBuilder system. It still excessively uses global variables, though I have refactored some of that away.

The frontend dates back to 2000 or so, and was written in the "C with Classes" style of the time. Of course, this is outdated today. It doesn't use templates because C++ templates of that time were terrible, and frankly, I still find them unpleasant to use.

A recent "D-ify" of it is the greatly expanded use of nested functions, and some lambdas.

On 6/10/2022 1:29 PM, deadalnix wrote:
> Joel is assuming that the typical refactoring and maintenance is happening to keep the complexity under control. This hasn't happened in DMD at all.

Never mind the refactorings I regularly do to it.

On Saturday, 11 June 2022 at 20:16:58 UTC, Walter Bright wrote:
> On 6/10/2022 1:29 PM, deadalnix wrote:
>> Joel is assuming that the typical refactoring and maintenance is happening to keep the complexity under control. This hasn't happened in DMD at all.
>
> Never mind the refactorings I regularly do to it.

Well maybe someday we'll have some kind of D compilation server like modern languages has today. Making recompilations a lot faster and actually modularizing DMD enough to make it work as a lib, so maybe a lot of people would not have the kind of hard work they have today.

Some people have attempt to do it but... Now they're simply gone.

On Saturday, 11 June 2022 at 12:57:25 UTC, Alexandru Ermicioi wrote:
> On Saturday, 11 June 2022 at 11:24:04 UTC, forkit wrote:
>> The module is not a type!
>>
>> I do not design my solution around the module. I design it around types, and I use the module to bring related types together.
>
> Then don't use module to bring related types yet not tightly coupled ones toghether. Use rather packages. It seems that your definition of module is more matching to a package in D rather than D module.

I don't. So the suggestion in irrelvant.

Package brings related modules together, not related types.

> It is indeed pain sometimes to have to create new modules, but you can argue that it is also pain to skim through thousands of lines of code in a single module.
>

Yes, exactly! one class per module, just to ensure the invariants of that class can be verified at compile time, is .. a pain!


>> Separate, unrelated types can go in their own module.
>>
>> In the event a type (and I'm talking about an instatiation of class here) - is a standalone type.. sure..it can go it's own module, no problem. Makes sense even.
>>
>> But you don't have to put every int your define into its own module, just so the compiler can enforce its invariants. That would be crazy.. yes?
>
> Why not? Why crazy?

I don't get it. Put every int into its own module? Is that what you're saying here?


> Usually a type (class/struct) is not just a single or two lines, but 10-20 at least. Imho it is perfectly fine to put them in single file. In java, that is how it is done, one file one public class.
>

Don't talk to me about Java ;-)

The problem is NOT, whether a type should go in its own module.

The problem, is being forced by the language, to put a type in its own module, just so you can ensure its invariants.

Please read above lines again, so you know what my argument actually is.


>> A class is just a type - why is it considered less a type than an int? (i.e. the only way to protect its invariants, is to put it all by itself in its own module.
>>
>> What utter nonsense!
>
> Obviously you're comparing apples with grapes. int is a built-in type and certainly not a class or struct, although making the builtin-types and user defined ones have homogeneous rules mostly, would be beneficial.
>

No. You cannot put "wft!" into a int. Its invariants are enforced (from code surrounding that int, in the same module). Not so with a class type.


>> The module is not a type. You do not design your solution using types.
>>
>> You do not instatiate a module, and start sending it messages, or recieve messages from it, or change its behavior, or have it change its own behavior.
>>
>> The module is a just convenient static encapsulation for related types.
>
> Well, why can't it be?
> You certainly can consider it being a singleton per thread, where global vars are it's internal state, and exported functions are the methods to class (module). Certainly it doesn't have inheritance and other OOP aspects, but saying that module is a bunch of related types only, is not right. Better to say, is that they are bunch of tightly coupled types, meaning that extracting one type into separate module most certainly would require the other types in module to be adjusted to the change (not by importing the new module, but actual code changes).
>

Again, this is not an argument as to whether a type should go in its own module.

This is an argument about the language forcing you to put a type (in this case a class type) into its own module, for the single purpose of enforcing the invariants of that type from surrounding code.

Please read above lines again, so you know what my argument actually is.


> In summary, the current access modifiers, don't make oop programming in D in any way less powerful, than any other language with comparable oop features.
>
> Best regards,
> Alexandru.

I don't agree. If I cannot enforce the invariants of my class type, from ANY code surrounding it (related or not), then that type is not longer a strong type, but a weak type - and this requires to you to restructure your design, to accomodate this .. flaw!

On Sunday, 12 June 2022 at 00:41:20 UTC, norm wrote:
>
> In a practical sense module scope encapsulation works really well, I find it much better than strict class encapsulation that then has to be broken anyway with friends. In fact I've not encountered one bug using module scope encapsulation. None. I have had many bugs in my code though using friends in C++!
>
> It is fascinating the amount of energy in D forums spent talking about D's shortcomings and reminds me of the internet in the late 90's early 00's where every forum chat ended in a flame war.
>
> All this energy would be much better spent making software with D or building up its ecosystem....but that requires work and not as much fun as pointing out someone is wrong on the internet. The latter requires no work at all for the same physiological response in the brain as recognition by others for a job well done.
>
> I guess it is the nature of the beast, D is so flexible and very good at so many things that people are unwilling to accept that D by design just doesn't do everything the way they want.

Nice distraction, yet again ;-)

This is not about 'strict' encapsulation.

How many times do I have to say this.. jeessssee........

I just want 'the option' to hide my invariants from other code in the module, and have the compiler enforce those invariants at compile time.

Really, it doesn't sound like such a big ask to me.

Why so many are against this, is puzzling, to say the least.