On Thursday, 27 May 2021 at 07:14:25 UTC, Mathias LANG wrote:
>On Thursday, 27 May 2021 at 06:08:53 UTC, Ola Fosheim Grostad wrote:
>If that is it, then we might as well close the thread and conclude that dmd is a hobby project.
Which is fair enough. Just don't pretend it aspires to be more than that, because that takes reorganization and restructuring.
Don't forget about the many contributors that have invested thousands of hours to understand and improve the code base :)
Yes, let us not forget that they wasted many unproductive hours on trying to understand... Let us put a number on that in dollars...
>While I disagree with many of Walter's arguments here, a refactorning has a lower barrier of entry than a bugfix, and is more prone to be subjective.
I dont want to enter that territory, neither bugfixes or micro level refactoring has much of an impact on people wanting to experiment. To enable that we have to look at the macro level and establish stable well designed interfaces so that changes in compiler internals have small impact on experimental components.
Well designed interfaces can hook up to internals you want to change at a later stage, but now you do at least not get more dependecies tied to things you want to replace.
So in essence, if there is a mess, first step is not to clean up the mess (could be too costly), but to hide it so that people stop depending on it.
My impression is that Walter is arguing that everything should be cleaned up first. That is not realistic.
>Now to talk about what can be done to improve the DMD codebase, it's fairly obvious: ELIMINATE ALL CASTS. But not by replacing cast(XXX)e
with e.isXXX()
, but by actually using proper encapsulation.
Does not enable experimentation. Only a good macro level architecture enables experimentation.
The internals can to some extent be a mess, with little impact, it does not matter unless you want to change templating or type system features.
Many interesting experiments can be done by combining parser mods, runtime mods and post frontend mods.
Other interesting improvements can be done if one identifies areas in the compiler that can be isolated from the whole and where new features could be enabled. I suspect this is needed to get a solver that provides proper type unification, but I havent looked at this...
Some stuff being messy is not the big picture issue.
The big picture is to get clean points in the codebase where you can inject your own component. And to put those injection points where they have most potential for enabling experimentation.
An easy first step is to put a separation layer between frontend and backend.