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

[Ola Fosheim Grostad]

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.