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

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sun May 23 06:12:30 UTC 2021


I think there are many that would like to experiment with the 
compiler, but feel discouraged because they don't know how to 
approach it.

I think this is not only comes down to documentation, but also is 
structural. In order to figure out what to improve, the best 
starting point is experienced challenges.

The number one challenge I see is keeping track of DMD as it is 
released with new improvements. Basically reapplying the changes 
made to the experimental branch to the main branch (aka 
"rebasing"?). I suspect that kills many efforts, meaning people 
create a fork, start making changes, but then a new version of 
DMD is released and the fork is left to dry in the sun as 
rebasing is not fun. And well, a hobby that isn't fun, is not a 
good hobby. :-D

Better internal compiler structure would help a lot with this. So 
a prioritized list for me would be:

1. Have a clean separation between frontend and backend, that is 
close to plug-and-play. That would allow people to inject a new 
high level IR between frontend and backend that could open for 
new interesting optimizations, and allow all the compilers to 
benefit from it.

2. Break down source files into smaller units, so that stable 
parts are separated from unstable parts.

3. More encapsulation and separation of responsibility.

4. Switch to a more syntactical AST, possibly enabling AST macros 
in the future without too much hassle, then use an IR for real 
work.

5. Use directories.

6. Improved documentation.

7. Tutorials.

What other items should be on the list?

Which items are feasible in the next 6 months?







More information about the Digitalmars-d mailing list