Andrei, I cannot catch these steps:

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

Since D is written on C++, what exactly you gonna convert to "C++ header"??

Anyway, I offer to keep away from C++ code - it's written with "C++ in mind", while D offers brand new world. So I support rewritting D on D from scratch.
Initially frontend only + join LLVM backend. And next (if we find LLVM not so well) we can write our own backend.

Am 01.03.2013 10:54, schrieb Vincent:
> Andrei, I cannot catch these steps:
>
>> 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.
>
> Since D is written on C++, what exactly you gonna convert to "C++
> header"??

it will be an incremental port using both C++ and D code
so the DMD C++ base needs headers from the D based module replacements

>Anyway, I offer to keep away from C++ code - it's written with
>"C++ in mind", while D offers brand new world. So I support
>rewritting D on D from scratch.

that will just not work for an project of that size - or better - there are several tries of from-scratch without success out there

an incremental port and then refactor is the best/fasted and error-free thing we can get

benefits:
-will help to find more bugs/missing features/tools in the C/C++ <-> D conversion/adaption area (which is still a big plus for D)

-keeps both the pure D and the semi-pure :) D guys (Walter,gdc,ldc frontend developers) in the same boat

-the dmd frontend will become the very first community driven BIG project that can be a much better orientation for bug-prevention designs/future D ideas etc. then every thing else

etc...

On 28 February 2013 22:50, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/28/2013 7:53 AM, Iain Buclaw wrote:
>
>> So, feel free to send me a list of questions you want me to answer. :o)
>>
>
> Would it impair having it accepted as part of gcc?
>
>
Not if we follow by way of example, eg: the Ada or Go model.  Where they have separately maintained code for their front end that may be used verbatim in multiple compilers, with the code outside the front end doing everything related to interfacing with GCC, and only what's related to interfacing with GCC.

The only part where this may be problematic for D is that there are still parts of the front end that require patching for use with GCC, this is being worked on, but would require co-operation from both code gdc, ldc and dmd maintains to align their copies of the front end up.


Regards
-- 
Iain Buclaw

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

On 1 March 2013 07:26, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-28 18:18, Iain Buclaw wrote:
>
>  We still do not know what portions of the frontend is being ported over
>> to D.  The way gdc is written, it takes the D Frontend, removes all C++ parts that interface with dmd's backend - toElem; toIR; toObjFile; toSymbol; toCtype; toDt (this latter one I am in the middle of removing from gdc) and implements them to instead build GCC trees, the code itself also being in C++.
>>
>> These are all methods defined in D Front-End, and rely on calling and interfacing with the gcc backend.  Re-writing these in D is not an option, as require access to GCC macros.
>>
>
> If you're removing these functions does it matter which language they're written in ?
>
> --
> /Jacob Carlborg
>


Not removed, re-written.  For example, VectorExp::toElem().

For gdc: https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-elem.cc#L2375 For dmd: https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L3820


Regards
-- 
Iain Buclaw

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

On 1 March 2013 07:28, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-28 16:53, Iain Buclaw wrote:
>
>  So, feel free to send me a list of questions you want me to answer. :o)
>>
>
> Could the GDC front end remain in C++ and changes be folded in anyway? These changes do not need to be direct translation of the D code.
>
> --
> /Jacob Carlborg
>

The code that interfaces with gcc needs to be in either C or C++.  There are C++ structs/classes defined in the D frontend that while they include all methods required for parsing/semantic analysis of D code.  They also include methods that are used to generate the codegen for the backend (toElem, toIR, toSymbol, etc).  In gdc, these are gcc interfacing methods that can't be converted to D.

-- 
Iain Buclaw

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

On 2013-03-01 11:23, Iain Buclaw wrote:

> Not removed, re-written.  For example, VectorExp::toElem().
>
> For gdc:
> https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-elem.cc#L2375
> For dmd:
> https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L3820

Aha, I see.

-- 
/Jacob Carlborg

On 1 March 2013 08:50, Thomas Koch <thomas@koch.ro> 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.
>
> Two points from the viewpoint of the Debian distribution:
>
> Debian is ported to many different platforms and in average one new
> platform
> port started every year. A huge pain point for porters are circular (or
> self) dependencies. A lot of effort goes into breaking such circles.
>
>
As I understand it, the biggest pain is getting an initial system compiler on the ported target in the first place.  One that package is in place, it gets easier to manage the circular dependency.


Regards
-- 
Iain Buclaw

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

On Friday, March 01, 2013 09:50:13 Thomas Koch 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.
> 
> Two points from the viewpoint of the Debian distribution:
> 
> Debian is ported to many different platforms and in average one new platform port started every year. A huge pain point for porters are circular (or self) dependencies. A lot of effort goes into breaking such circles.
> 
> So in the moment the D language is great in that it does not introduce a new circular dependency. It would be a pity to lose this.
> 
> The second important thing for Debian (and Fedora and others) is licensing. It's a pity that DMD isn't free software and I believe DMD not being in distros is one reason for the low popularity of D. It's hard to learn D with gdc while all tutorials are based on DMD.
> 
> So instead of a rewrite of D, it would rather be important (from my humble point of view) to replace non-free parts of DMD.

I don't really care about the license, but I can definitely say that part of me finds the idea of having a compiler compiling itself to be a bad idea, much is compiler folks love to do that. Recently, I had some older haskell code that I needed to compile, but it followed the previous haskell standard, and I couldn't get the current compiler to compile it even in compatability mode. So, I tried to compile an older version of the compiler from before the new standard, and it had exactly the same problems that my code did, because it was written in haskell using the older standard. So, I had to give up on being able to compile my code, because I couldn't get my hands on an old enough version of the compiler. If they'd just written it in C/C++, then I wouldn't have had that problem.

I know that it's generally touted as a great idea for a language to compile itself, and I'm sure that it would be great to be able to use D's features in the compiler, but the circular dependency that that causes is a definite negative IMHO.

- Jonathan M Davis

On 2013-03-01 11:29, Iain Buclaw wrote:

> The code that interfaces with gcc needs to be in either C or C++.  There
> are C++ structs/classes defined in the D frontend that while they
> include all methods required for parsing/semantic analysis of D code.
> They also include methods that are used to generate the codegen for the
> backend (toElem, toIR, toSymbol, etc).  In gdc, these are gcc
> interfacing methods that can't be converted to D.

Can you use the current toElem, toIR and toSymbol written in C++. Then port in changes from the version written in D as needed?

-- 
/Jacob Carlborg

On 1 March 2013 10:43, Jacob Carlborg <doob@me.com> wrote:

> On 2013-03-01 11:29, Iain Buclaw wrote:
>
>  The code that interfaces with gcc needs to be in either C or C++.  There
>> are C++ structs/classes defined in the D frontend that while they include all methods required for parsing/semantic analysis of D code. They also include methods that are used to generate the codegen for the backend (toElem, toIR, toSymbol, etc).  In gdc, these are gcc interfacing methods that can't be converted to D.
>>
>
> Can you use the current toElem, toIR and toSymbol written in C++. Then port in changes from the version written in D as needed?
>
> --
> /Jacob Carlborg
>

It's much more complex than that.  Think about compatibility between calling D structs/classes from C++, and that dmd and gdc don't share the same representation of types in the back-end that are common to the front-end - elem, type, IRState, real_t, to name a few.


Regards
-- 
Iain Buclaw

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