On 2/27/13 8:07 PM, John Colvin wrote:
> What will this mean for licensing? Will we be able to fully free the
> backend?

The backend will stay as is.

Andrei

On Thursday, 28 February 2013 at 01:05:08 UTC, 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.

I think the one I started a while ago is still sitting up on github.

On 2/27/2013 4:37 PM, Andrei Alexandrescu wrote:
> 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).

Not exactly - the back end will not realistically be converted to D. This is a front end only conversion.

On Thursday, 28 February 2013 at 01:12:06 UTC, Andrei Alexandrescu wrote:
> On 2/27/13 8:07 PM, John Colvin wrote:
>> What will this mean for licensing? Will we be able to fully free the
>> backend?
>
> The backend will stay as is.
>
> Andrei

Ah, so we're just bootstrapping the frontend, not the whole compiler.

This presents a good opportunity to make the frontend completely backend agnostic (I don't know how close it is currently).

On 2/27/13 8:12 PM, Adam D. Ruppe wrote:
> On Thursday, 28 February 2013 at 01:05:08 UTC, 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.
>
> I think the one I started a while ago is still sitting up on github.

Did you finish it?

Andrei

On 2/27/2013 5:07 PM, John Colvin wrote:
> What will this mean for licensing? Will we be able to fully free the backend?

The backend will not be part of this conversion project in the foreseeable future.

And besides, a translation of the backend into D will not void its license.

On 2/27/2013 4:57 PM, H. S. Teoh wrote:
> 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'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.

On Thursday, 28 February 2013 at 00:37:50 UTC, Andrei Alexandrescu wrote:
> Please chime in with ideas on how to make this happen.

Not an expert on the topic, but what does this mean for maintainers of integration with other backends, like GDC and LDC? For example: are there any other frontends in GCC not written in C/C++?

On Thursday, 28 February 2013 at 01:12:47 UTC, Adam D. Ruppe wrote:
> On Thursday, 28 February 2013 at 01:05:08 UTC, 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.
>
> I think the one I started a while ago is still sitting up on github.

Yep. https://github.com/adamdruppe/tools/blob/dtoh/dtoh.d

Andrei Alexandrescu:

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

If just the front-end is written in D, then I think it can't be defined a bootstrapping, because you still need a C++ compiler to compile a complete D compiler.

Bye,
bearophile