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