Migrating dmd to D?

[Robert burner Schadek]

On 02/28/2013 02:11 AM, Ary Borenszweig wrote:
> On 2/27/13 9:37 PM, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> Walter and I have had a long conversation about the next radical thing
>> to do to improve D's standing. Like others in this community, we believe
>> it's a good time to consider bootstrapping the compiler.
>
> If you do it, I think it's an excellent opportunity to rewrite the 
> compiler *from scratch*, using features in D, and probably using a 
> better design. It's probably easier to design the compiler now that 
> all the features are more or less known. I also remember that DMD 
> didn't have a visitor of sort for the semantic analysis.
>
+1

I think translating the frontend from C++ to D will yield very bad code. 
The AST Node types in dmd use struct with inheritance. This leads to the 
question whether or not to use structs or classes in the D frontend. If 
classes are used the GC will hit you from time to time, so class are not 
a good idea. Sure the GC could be disabled, but imho will lead to the 
same problems the frontend has now. Using struct will also require to 
use heap an pointers, also bad, but imho there are great benefits by 
from structs and there is a GC workaround for structs. Structs will make 
it easier to make the frontend into a library and use it from anything 
that knows C. This is a huge +1 imo. To get around the GC, the AST could 
be build using shared_ptr pointing to structs. Sure this will have a 
overhead, but I would rather see the compiler taking longer than telling 
me "no more memory available". I would also argue that a clean room D 
impl. with tons of unittests, testings all parse methodes, the lexer, 
the semantic analyzer etc, will yield a much better maintainable and bug 
free compiler.

Pro clean room with shared_ptr!(ASTNode):
  - Binding from C
  - fixes memory problem
  - more maintainable code