On 2/27/2013 5:11 PM, Ary Borenszweig wrote:
> 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.
>

My experience with such things is it, while tempting, has a large probability of destroying the project entirely.

On Thursday, 28 February 2013 at 01:32:58 UTC, Vladimir Panteleev
wrote:
> 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++?

gcc only started accepting c++ in 2010. So it will be really
though to get them to accept D.

On 2/27/13 10:58 PM, Walter Bright wrote:
> ures 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.

Why? What happened?

If you don't use all D features and plan the compiler for being written in D I don't think the compiler will be a good candidate for stress-testing the language.

It's also more fun to do it from scratch. What's the hurry?

Walter Bright:

> My experience with such things is it, while tempting, has a large probability of destroying the project entirely.

I agree.
And translating code must be done in an extremely methodical way, if you want one chance to see a working result :-) In such work taking short-cuts gives a high probability of producing trash. You have to go slowly, and double test every intermediate step.

Bye,
bearophile

On 2/27/2013 6:12 PM, Ary Borenszweig wrote:
> Why? What happened?

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.

You wind up with one very large step change, and it doesn't work, and you're lost.

Another reason is the people doing the translation/refactoring have an inadequate grasp of why the code is the way it is, so they just wind up breaking it. The resulting frustration and finger-pointing ruins everything.

Translate. Test. Verify. *THEN* refactor. Because when the verify step fails, and you have a one:one correspondence to the original code that does work, you can quickly find out what went wrong. And believe me, things go wrong in the translation at every step of the process.


> If you don't use all D features and plan the compiler for being written in D I
> don't think the compiler will be a good candidate for stress-testing the language.

The point is not to use the compiler to stress test the language. NOT AT ALL. The point is to improve the compiler by taking advantage of what D offers.


> It's also more fun to do it from scratch. What's the hurry?

We have limited resources, and we shouldn't squander them on something I have a lot of experience on knowing will fail.

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 > 1000 open bugs and well known, expected language
features not implemented. In my opinion, the compiler should
be ported after all important language features are finalized.
I don't mean syntax, but stuff that only bearophile has the
complete list of: shared, allocators, ...
Also DMD leaks memory -> it is tempting to use the GC -> DMD
will often be a whole lot slower in the end. :D
Also Phobos is designed for safety and generic programming,
not for raw speed like many old C functions (at least that's
my experience). E.g. I have seen or written Unicode and
float/string conversion routines that perform 7x to 13x faster
than the 'obvious' way in D.

-- 
Marco

On 2/27/2013 8:03 PM, Marco Leise wrote:
> There are > 1000 open bugs and well known, expected language
> features not implemented. In my opinion, the compiler should
> be ported after all important language features are finalized.
> I don't mean syntax, but stuff that only bearophile has the
> complete list of: shared, allocators, ...
> Also DMD leaks memory -> it is tempting to use the GC -> DMD
> will often be a whole lot slower in the end. :D
> Also Phobos is designed for safety and generic programming,
> not for raw speed like many old C functions (at least that's
> my experience). E.g. I have seen or written Unicode and
> float/string conversion routines that perform 7x to 13x faster
> than the 'obvious' way in D.


The motivation for the migration is not for fun, it's not even to "eat our own dogfood". The idea is to make the front end more reliable and more flexible by using D features that help. This should make us more productive and able to fix problems faster and presumably have fewer problems in the first place.

There are a long list of D things that will help.

On Wed, Feb 27, 2013 at 09:32:08PM -0800, Walter Bright wrote: [...]
> The motivation for the migration is not for fun, it's not even to "eat our own dogfood". The idea is to make the front end more reliable and more flexible by using D features that help. This should make us more productive and able to fix problems faster and presumably have fewer problems in the first place.
> 
> There are a long list of D things that will help.

How does this affect GDC/LDC? AFAIK, the GCC build scripts do not (yet?) support bootstrapping D code.


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener

On Feb 28, 2013 1:31 AM, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> 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)g . 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.
>

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.

Regards
Iain

On Feb 28, 2013 1:40 AM, "Vladimir Panteleev" <vladimir@thecybershadow.net> wrote:
>
> 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++?

Before gdc, there was no such thing as a frontend written in C++ in gcc. As far as history goes this was a huge drawback to make any progress in the development of a gcc D compiler.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';