On 2013-02-28 01:37, 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.

Now this is some great news to wake up to :)

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

Short term goal:

I agree with what Walter has said in other posts that we need to make a direct translation as possible minimize translation bugs.

Long term goal:

When the translation is done we should refactor the compiler/front end to be a library, usable by other tools.

It would be nice to hear some comments from the GDC and LDC developers.

BTW, there's already a translation of DMD available, DDMD:

http://www.dsource.org/projects/ddmd

But this is a bit outdated. I also don't know how a direct translation this is. I can at least tell that it has a more one-to-one mapping of files and classes than DMD does.

-- 
/Jacob Carlborg

On 2013-02-28 01:37, Andrei Alexandrescu wrote:

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

BTW, how are we going to bootstrap the compiler on any possibly new platforms? Cross compiling?

-- 
/Jacob Carlborg

On 2013-02-28 02:05, Andrei Alexandrescu wrote:

> I think that's a fine idea but I also believe dtoh would be a mightily
> powerful program in and by itself. Once available, it would make
> migration of C++ projects to D possible and easy.

It depends on where we want to put our time.

-- 
/Jacob Carlborg

On 2013-02-28 02:22, Walter Bright wrote:

> I've done many projects consisting of converting a medium sized code
> base from one language to another. The way that works is to do it
> incrementally. Incrementally means:
>
> 1. at each step (i.e. pull request) we will have a fully functioning D
> compiler that passes its test suite
>
> 2. there is no divergence in code bases because there is not a divergent
> code base.
>
>> 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.
>
> My experience chiming in - never ever ever attempt to refactor while
> translating. What always happens is you wind up with a mess that just
> doesn't work.
>
>
>> 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.
>
> Experience chiming in - a successful model is that the HEAD is compiled
> by the previous official release of D.

I agree with Walter here.

-- 
/Jacob Carlborg

On 2013-02-28 07:45, Iain Buclaw wrote:

> Once HEAD is compiled by the previous release (or system D compiler), it
> might be a good practice for HEAD to compile itself too. Then this
> compiler built by HEAD will then build the library.

This is a good idea.

-- 
/Jacob Carlborg

On 2/27/2013 9:35 PM, H. S. Teoh wrote:
> How does this affect GDC/LDC? AFAIK, the GCC build scripts do not (yet?)
> support bootstrapping D code.

I don't know. I presume other gcc language tools are not written in C.

On 2/27/2013 11:34 PM, Jacob Carlborg wrote:
> BTW, there's already a translation of DMD available, DDMD:
>
> http://www.dsource.org/projects/ddmd
>
> But this is a bit outdated. I also don't know how a direct translation this is.
> I can at least tell that it has a more one-to-one mapping of files and classes
> than DMD does.
>

Curiously, there appears to be no copyright/license information.

On 2013-02-28 04:49, Walter Bright wrote:

> There's a lot of lore in the original code involving arcana about how
> things really work. If you refactor and translate at the same time, you
> don't have an incremental conversion you can run through the test suite
> at each step.

I interpreted Ary's post as basically doing a clean room implementation. Not translate the existing code.

> Hey, anyone can ignore me and go ahead and do it that way. I wish you
> the best of luck - sometimes us old coots are dead wrong - but forgive
> me if I'm not going to be terribly sympathetic if you ignore my advice
> and things go badly!

There are already several people doing clean room implementations. At least of the front end.

* Dil
* SDC
* A couple of lexers/parsers

-- 
/Jacob Carlborg

On Wednesday, February 27, 2013 23:44:02 Walter Bright wrote:
> On 2/27/2013 9:35 PM, H. S. Teoh wrote:
> > How does this affect GDC/LDC? AFAIK, the GCC build scripts do not (yet?) support bootstrapping D code.
> 
> I don't know. I presume other gcc language tools are not written in C.

Wasn't all of that stuff written in pure C until fairly recently when they finally started letting C++ in? Maybe that was only the core stuff though and some of the language extensions aren't that strict. I don't know.

- Jonathan M Davis

Am 28.02.2013 01:37, schrieb Andrei Alexandrescu:
> 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.
>
> 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).

sounds like an very good idea, incremental stupid ports - refactoring comes later when the port is as bug-free as original

and this will also shape dtoh to an even better state

next question is - is there any way of semi-auto conversion of the code itself possible?