How can we make it easier to experiment with the compiler? (page 2)

On Monday, 24 May 2021 at 06:00:06 UTC, Andrei Alexandrescu wrote: > refactoring. I find it confusing that people push for massive reorganization for years, but won't bother to create 50 line PRs that add `private` appropriately. Yes, but I'd like this thread to be more forward-looking and focus more on making compiler hacking a "fun hobby" rather than being one of should-have-in-the-past. The key "sociological" point one could take away from this is: 1. Do boring chores together, because that makes them less unfun. 2. Then leave the smaller fun things to individuals that have sporadic activity (busy life or weak affiliation with the project). 3. Encourage a sense of autonomous ownership, and experimental forks is a very good way to achieve that. Research on school children shows that a sense of autonomous ownership of the task is a good motivation aspect. (Not sufficient, but close to necessary.) (To do unfun chores together we need a plan and some sort of model or map).

On Monday, 24 May 2021 at 02:25:33 UTC, Nicholas Wilson wrote: > On Sunday, 23 May 2021 at 06:12:30 UTC, Ola Fosheim Grøstad >> 5. Use directories. > > Yes!!! sooo much yes! see above. > You can't complain unless you've had a go at making a change to Ada. [gcc] (master) $ ls gcc/c | wc -l 19 [gcc] (master) $ ls gcc/cp | wc -l 87 [gcc] (master) $ ls gcc/fortran | wc -l 99 [gcc] (master) $ ls gcc/d/dmd | wc -l 114 [gcc] (master) $ ls gcc/ada | wc -l 565 I do tend to agree though that we should try to respect Dunbar's number when it comes to these things. But the individual file count does not map to reality.

On 5/24/2021 1:40 AM, poffer wrote: > A good enhancement to the language would be adding some sort of module declaration that just states the admitted import packages or modules. I know that could be done by an external tool, but I feel that this one is a common problem. Importing unused modules is a problem, but a minor one. The larger problem is needing those modules.

May 24, 2021

Re: How can we make it easier to experiment with the compiler?

Posted by Alexandru Ermicioi
in reply to Ola Fosheim Grøstad

Permalink

Alexandru Ermicioi

Posted in reply to Ola Fosheim Grøstad

Permalink

On Sunday, 23 May 2021 at 06:12:30 UTC, Ola Fosheim Grøstad wrote:

Tutorials.

Proper module naming, not abbreviations. Abbreviations need to be remembered, and that is additional mental workload for new volunteer.
Proper variable naming, not abbreviations. I really tried to understand some code, but got discouraged once met all those abbreviated variable names, I literally had to stuff all my memory with what those abbreviations meant instead of trying to keep the thread of the logic that code is implementing.
Split up humongous methods and objects, they are rude to new volunteers, and discourages any code improvement.
Perhaps some tutorial, on how to orient in all dmd internals, with a nice abstract class diagram explaining key elements of dmd objects and how they interact between themselves. This would allow at least some kind of overview of what does what in dmd, and how they interact.

I really was interested in doing some dmd bug fixes, but 8,9, and 10, make the code to take too much time, and willpower to just understand it. It was and is a huge barrier for me to try and fix/improve dmd.

P.S. And no, e,exp,aa and other kind of abbreviations except for loop indexes, are not always obvious, and do take mental power and memory, while trying to understand existing code. They are not simple for new volunteers to dmd.

Best regards,
Alexandru.

On Monday, 24 May 2021 at 02:56:14 UTC, Walter Bright wrote: > import dmd.argtypes_x86; > import dmd.argtypes_sysv_x64; > import core.stdc.string : strlen; > import dmd.cond; > import dmd.cppmangle; > import dmd.cppmanglewin; > import dmd.dclass; > import dmd.declaration; > import dmd.dscope; > import dmd.dstruct; > import dmd.dsymbol; > import dmd.expression; > import dmd.func; > import dmd.globals; > import dmd.id; > import dmd.identifier; > import dmd.mtype; > import dmd.statement; > import dmd.typesem; > import dmd.tokens : TOK; > import dmd.root.ctfloat; > import dmd.root.outbuffer; > import dmd.root.string : toDString; > > If I want to understand the code, I have to understand half of the rest of the compiler. On a more abstract level, why on earth would a target abstraction need to know about AST nodes? At least half of these imports shouldn't be here, and if they are, the code needs to be redesigned. > To be fair, most of this is imported because a function needs the definition of one or more symbols. This can be made better by either: 1. Making these selective imports, or... 2. Moving type definitions of AST nodes into modules that _only_ contain definitions.

On Monday, 24 May 2021 at 09:41:08 UTC, Iain Buclaw wrote: > On Monday, 24 May 2021 at 02:25:33 UTC, Nicholas Wilson wrote: >> On Sunday, 23 May 2021 at 06:12:30 UTC, Ola Fosheim Grøstad >>> 5. Use directories. >> >> Yes!!! sooo much yes! see above. >> > > You can't complain unless you've had a go at making a change to Ada. > > [gcc] (master) $ ls gcc/c | wc -l > 19 > [gcc] (master) $ ls gcc/cp | wc -l > 87 > [gcc] (master) $ ls gcc/fortran | wc -l > 99 > [gcc] (master) $ ls gcc/d/dmd | wc -l > 114 > [gcc] (master) $ ls gcc/ada | wc -l > 565 Eee gads! > I do tend to agree though that we should try to respect Dunbar's number when it comes to these things. But the individual file count does not map to reality. it makes it difficult to navigate, especially so when you are unfamiliar with the code base.

On 5/23/2021 10:55 PM, Andrei Alexandrescu wrote: > One problem with that is code duplication. Sure. But in the outbuffer case, the duplication stems from backend being used in multiple projects. It's hard to have perfection, and if getting to perfection means driving off a cliff (!) it's better to just live with a bit of imperfection here and there. I don't like having two outbuffers, but the cure is worse for that particular case. There's even another implementation of outbuffer in Phobos (because I thought outbuffer was generally very useful): https://dlang.org/phobos/std_outbuffer.html But here we run into our rule that dmd shouldn't rely on Phobos. Compromise is inevitable. Outbuffer isn't a spike we need to impale ourselves on. There are plenty of other encapsulation problems that could be improved, like target.d.

On Monday, 24 May 2021 at 06:58:48 UTC, Walter Bright wrote: > On 5/23/2021 10:15 PM, Nicholas Wilson wrote: >> This is a _completely_ orthogonal problem. > > It's the same problem. > > D's support for modules and packages is literally designed around matching the hierarchy of the source files. > > Shuffling files around accomplishes nothing when every module imports every other module. It will be a huge help if they are though. At minimum it will organize the things into packages that have one purpose, which will help in understanding the structure of dmd, and also make navigation and search of desired functionality easier, compared to one flat package. This can actually be the first step at unwinding all the mess with imports you're mentioning, since packages are not just folders, but logical organization of a set of modules that are somewhat related to the purpose the package has.

On 5/24/2021 2:39 AM, Walter Bright wrote: > On 5/24/2021 1:35 AM, Nicholas Wilson wrote: >> Did you read _literally nothing else_ that I wrote? > > I read it, my response was to the entire posting. To be a little clearer, if the files are all merely reshuffled into various packages, then they all violate the rule: *** Never import a file from an uplevel directory *** and understanding is not increased at all. And it isn't even just an uplevel directory, it's up then sideways then down. There *is*, however, documentation on the dmd source files: https://dlang.org/phobos/index.html Click on "dmd" on the left. For anyone wishing to get a tour of the files and what they do, this is the place. Adding better Ddoc comments to the source files will help with this, of course.

Forums