Migrating dmd to D?

[H. S. Teoh]

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?


> 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.

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.

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.


T

-- 
Without geometry, life would be pointless. -- VS