Migrating dmd to D?

[Andrei Alexandrescu]

On 2/27/13 7:57 PM, H. S. Teoh wrote:
> On Wed, Feb 27, 2013 at 07:37:50PM -0500, 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.
>> Having the D compiler written in D has quite a few advantages, among
>> which taking advantages of D's features and having a large codebase
>> that would be its own test harness.
>
> Aren't there already parts of a D compiler written by various community
> members? IIRC, Timon has a prototype D compiler that supports quite a
> good subset of D already. And I believe there are various D lexers and
> parsers lying around, some of which may serve as the basis of a
> bootstrapping D compiler.
>
> Shouldn't we make use of these existing efforts instead of starting from
> ground zero?

Of course. This is the purpose of this entire discussion - to leverage 
existing and new ideas, talent, and code.

>> By this we'd like to initiate a dialog about how this large project
>> can be initiated and driven through completion. Our initial basic
>> ideas are:
>>
>> 1. Implement the dtoh standalone program that takes a D module and
>> generates its corresponding C++ header.
>>
>> 2. Use dtoh to initiate and conduct an incremental port of the
>> compiler. At given points throughout the code D code will coexist
>> and link with C++ code.
>>
>> 3. At a point in the future the last C++ module will be replaced
>> with a D module. Going forward there will be no more need for a C++
>> compiler to build the compiler (except as a bootstrapping test).
>>
>> It is essential that we get support from the larger community for
>> this. This is a large project that should enjoy strong leadership
>> apart from Walter himself (as he is busy with dynamic library
>> support which is strategic) and robust participation from many of
>> us.
> [...]
>
> How will this work with the continual stream of fixes that the current
> C++-based compiler is getting? I assume we're not just going to put DMD
> development on hold.

I don't have all answers. I do have some ideas though. I'm thinking we 
need a wedge first - dtoh in place, and one seed D file in the middle of 
the C++ project. For example the module containing the main function. 
Then I imagine there will be pull requests that delete entire modules 
and replace them with .d modules. We need to have a form of a protocol 
that "freezes" modules that are under translation.

> Also, wouldn't this be a good time to review some of the current designs
> in DMD that may be hampering the full implementation of features that
> we'd like, such as discrepancies with TDPL, etc.? Would it make sense to
> redesign some of the code currently causing hard-to-fix issues as we're
> porting that part of DMD into D? It seems a bit counterproductive to
> simply transcribe the current buggy code into D, only to rewrite it
> later when (if) we finally get round to fixing it.

I think fixing while translating is difficult and should be approached 
on a case basis.

> Finally, I think somebody has brought up the idea of "freezing" a
> particular subset of D that the D compiler can use in its own code,
> preferably a reasonably simple subset that is safe from breaking changes
> down the road (it would be pathetic if a breaking change causes the
> compiler to be unable to compile itself, because the source code uses a
> language construct that was later deemed to need redesign). As DMD is
> ported over to D, it should be restricted to using only this subset of
> the language, so that it does not hamper future developments of the
> language unnecessarily.

Far as I can tell the freeze is "last non-bootstrapped version is D 
2.xxx" and go from there.


Andrei