I want to contribute to the development of the dlang language, but I feel that I am insufficient, so I want to ask the big guys, can I participate in the development of the Dlang language after learning the principles of compilation?

On Monday, 13 September 2021 at 00:53:06 UTC, leikang wrote:

Yes. If you make a PR it should be and will be judged based on the code and only the code, not where or who it came from.

On Monday, 13 September 2021 at 03:00:07 UTC, max haughton wrote:

Are there any recommended books or videos to learn about the principles of compilation? What else should I learn besides the principles of compilation?

On Monday, 13 September 2021 at 03:21:37 UTC, leikang wrote:

Check out this video: DConf 2016 Day 2 Keynote: Spelunking D Compiler Internals -- Walter Bright
Just browsing dmd's source code and watching dmd's Pull Request queue is a good way to get familiar with the code and see what a bug fix looks like. Try to start with something small, like error message improvements or refactorings listed in the contributing guide. If you have any questions along the way, just ask them.

On Monday, 13 September 2021 at 04:08:53 UTC, rikki cattermole wrote:

The dragon book is really really showing it's age these days so I would highly recommend getting a copy but not reading it fully. "Engineering a compiler" is much better pedagogically. The dragon book barely mentions SSA for example, although the sections they did properly bother to update towards the end are quite interesting.

"Crafting interpreters" is quite good, I recommend it for learning how to actually write a parser without getting bogged down in totally useless theory.

Stephen Muchnick's "Advanced Compiler Design and Implementation" is the bible for optimizations, but uses a very weird unimplemented language so be careful for bugs.

"Optimizing Compilers for Modern Architectures: A Dependence-based Approach" is the only book I'm aware of that actually covers even the beginnings of modern loop optimizations thoroughly. Even this however is still somewhat set back by it being written 20 years ago, the principles are the same but the instinct is not i.e. memory latency is worse, ILP is much better.

What all of these books have in common, by the way, is that they were all written at a time when it was assumed that x86 would go the way of the dodo. So there is a somewhat significant deviation from "theory" and practice in some parts as (say) x86 SIMD is quite different from how the authors of the aforementioned book expected the world to go.

On Monday, 13 September 2021 at 00:53:06 UTC, leikang wrote:

In addition to what others have said: there are many ways you can contribute to D without needing to know anything about compiler internals. For example, you could fix one of the many known bugs in the standard library, or improve the documentation.

In general, there are more things that need to be done in D than there are people with the time to do them, so any contribution is valuable.

On Monday, 13 September 2021 at 10:23:14 UTC, Dennis wrote:

Thanks！