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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon May 24 20:28:05 UTC 2021


On 5/24/21 5:46 AM, Iain Buclaw wrote:
> On Monday, 24 May 2021 at 02:56:14 UTC, Walter Bright wrote:
>>   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.
>>
> 
> To be fair, most of this is imported because a function needs the 
> definition of one or more symbols.  This can be made better by either:
> 
> 1. Making these selective imports, or...
> 2. Moving type definitions of AST nodes into modules that _only_ contain 
> definitions.

Yes, and these are good incremental steps that help a lot, are low cost, 
and inform larger refactorings. There should be active work on pushing 
imports down to where they're used.

My dream: top-level imports will become an antipattern in large D code.


More information about the Digitalmars-d mailing list