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

[poffer]

On Monday, 24 May 2021 at 02:56:14 UTC, Walter Bright wrote:
> On 5/23/2021 7:25 PM, Nicholas Wilson wrote:
>> Directories.
>
> The #1 problem isn't directories, it's "every module imports 
> every other module" that leaves one with nowhere to start.
>
> We currently have:
>
>   dmd
>   dmd/root
>   dmd/backend
>
> I regularly fend off attempts to have dmd/root import files 
> from dmd, and dmd/backend import files from dmd. I recently had 
> to talk someone out of having dmd/backend import files from 
> dmd/root.
>
> In other words, a failure of encapsulation.
>
> Let's look at one example, picked more or less because I've 
> looked at it recently, dmd/target.d. The reason for its 
> existence is to abstract target information. It's imports are:
>
>   import dmd.argtypes_x86;
>   import dmd.argtypes_sysv_x64;
>   import core.stdc.string : strlen;
>   import dmd.cond;
>   import dmd.cppmangle;
>   import dmd.cppmanglewin;
>   import dmd.dclass;
>   import dmd.declaration;
>   import dmd.dscope;
>   import dmd.dstruct;
>   import dmd.dsymbol;
>   import dmd.expression;
>   import dmd.func;
>   import dmd.globals;
>   import dmd.id;
>   import dmd.identifier;
>   import dmd.mtype;
>   import dmd.statement;
>   import dmd.typesem;
>   import dmd.tokens : TOK;
>   import dmd.root.ctfloat;
>   import dmd.root.outbuffer;
>   import dmd.root.string : toDString;
>
> If I want to understand the code, I have to understand half of 
> the rest of the compiler. On a more abstract level, why on 
> earth would a target abstraction need to know about AST nodes? 
> At least half of these imports shouldn't be here, and if they 
> are, the code needs to be redesigned.
>
> Recently I needed some target information in the ImportC lexer, 
> and it would have been so easy to just import dmd.target. But 
> then that drags along all the imports that I've really tried to 
> avoid importing into the lexer.
>
> Iain came up with a clever solution to use a template parameter.
>
> Note that Phobos suffers terribly from this disease (everything 
> ultimately imports everything else), which makes it very hard 
> to understand and debug.
>
> Fixing this is not easy, it requires a lot of hard thinking 
> about what a module *really* needs to do. But each success at 
> eliminating an import makes it more understandable.
>
> Creating a false hierarchy (an implied relationship that is 
> instantly defeated by the imports) of files won't fix it.
>
> A good rule of thumb is:
>
>     *** Never import a file from an uplevel directory ***
>
> Import sideways and down, never up.

A good enhancement to the language would be adding some sort of 
module declaration that just states the admitted import packages 
or modules. I know that could be done by an external tool, but I 
feel that this one is a common problem.