Am Wed, 27 Feb 2013 21:32:08 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

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

In a way it means "eat your own dogfood" if you compare C++ to
D. C++ may be lacking, but you can emulate a few things and it
has good code analysis tools.
Maybe I'm too pessimistic in thinking this will take a year,
stop bug fixes and stall language design issues from being
resolved as well as slow the compiler down notably, since
you'll be writing easy to maintain code using Phobos and a GC
and that is always slower than ASM, right? :p

-- 
Marco

On 28 February 2013 16:01, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 2/28/13 10:53 AM, Iain Buclaw wrote:
>
>> On 28 February 2013 15:24, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >>
>>
>> wrote:
>>
>>     On 2/28/13 5:03 AM, deadalnix wrote:
>>
>>         That will impair GDC and LDC quite a lot.
>>
>>
>>     Let's see what the respective project leaders say.
>>
>>     Andrei
>>
>>
>>
>> I'll provide facts, but I'll reserve any opinion to myself.
>>
>> So, feel free to send me a list of questions you want me to answer. :o)
>>
>
> "Would an initiative of porting dmd to D create difficulties for gdc?"
>
> Andrei
>


Gnat's frontend is written in Ada, however it does not depend on having to call anything from the gcc backend.

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.

See tree.h for the majority of that list: http://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/tree.h;hb=refs/heads/master


-- 
Iain Buclaw

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

On 02/28/2013 03:02 PM, Jacob Carlborg wrote:
> On 2013-02-28 11:25, Walter Bright wrote:
>
>> Why? The only point would be to change the license of the front end.
>
> I don't know, I'm not doing it. Possibly reasons:
>
> * Fun

Yup.

> ...
> * Change the license

Actually I dislike the whole licensing issue.

> * DMD is not written in D

Yup.

> * DMD is not built/usable as a library

Yup. There should be a sufficiently simple frontend on which libraries for source code analysis and manipulation tools can be built.

> * DMD contains a lot of bugs
>

Yup, even the intention on the compiler developer side is buggy sometimes. DMD will keep breaking my code because the hand-wavy notion of a "forward reference error" somehow appears to be accepted.

* Having only one implementation harms the language quality, because people are more likely to be willing to accept arguably buggy or stupid behaviour, and there is no pressure to clarify details of the spec. (eg. UDA's in DMD introduce an awkward and underpowered AST macro system. Value range propagation is too conservative for bitwise operations, DMD contains undocumented features, like types as function arguments in a typeof, or invoking opCall via an assignment, etc.)

* wc -l reveals that the DMD front end source code is roughly 30 to 40 times larger than it should be for what it does in my opinion. Refactoring it so that it shrinks by that factor in C++ is a lot harder than building it from scratch in D.


(* Knowing the guts of a front end means you can decide to add type system and syntax extensions for private use. :P)

> Although I don't know for sure if they're clean room implementations or
> not. They are at least not direct translations.
>

Mine is clean room.

On Wed, Feb 27, 2013 at 6:37 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> 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.
>
> 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.
>
> Please chime in with ideas on how to make this happen.
>
>
> Thanks,
>
> Andrei
>

Having ported Boost.units to D, I can attest to this being a lot of work. I did try translating first and then refactoring the code, but that did not go well, mainly because of all the tricks and hacks employed when doing template meta-programming in C++ that did not translate well at all to D. With my first attempt I pretty much ended up with C++ code that was written in D, and that's not what I wanted.  So I had to start over, refactoring and writing D code in D as I went.  The problem with refactoring is that once you refactor a piece, chances are that you will need to refactor everything that depends on the code that was refactored, and that starts a domino effect.

Of course, things are different with DMD, so translating first and then refactoring is probably the right way to do it. But, I don't see how we could use D's nice features without refactoring.  So, I presume this is going to be done in two phases:

Phase 1: direct translation to make sure everything works. Phase 2: refactoring to use D's nice features.

And your three steps would be describing Phase 1.


Arlen

I believe a complete rewrite from the ground up using a fixed stable dmd is needed. The reason is two fold: Many things have been learned about the evolution of the D language over time. Much of the trouble of D has been stabling the D implementation and spec. Second, Trying to port the C++ code to D to make a D compiler will only multiply the bugs in DMD. (i.e., it will introduce new bugs from the conversion and retain the old bugs)

Instead, I believe proper project management is needed along with a SOLID language specification and clear delineation of goals. If the language spec itself is flawed then the same things will occur as is with DMD.

To tie the dependence on C/C++ the D compiler would need to be written in the language subset of the intersection between DMD and the new language spec. This should not be hard to do but must be strictly maintained. Else one will always require dmd to compile the compiler.

Hence, a solid language spec for the new D compiler is needed. The language spec must overlap with the old spec and the D compiler must only be written in this overlap. (It should be obvious but this allows the D compiler to be compiled in DMD or itself, after the bootstrap one can gradually evolve the subset to include the newer features a few versions behind since the old dmd is not needed)

The problem with such an undertaking behind successful is all in the project management. I would say we need a solid language spec and the subset between it and the current spec(frozen at some point). I imagine they would be almost identical so actually little real work would be needed.

So, who's up for writing the D 3.0 spec?

On Thursday, 28 February 2013 at 07:58:31 UTC, Jonathan M Davis wrote:
> 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

GNAT is written in Ada.

If I am not mistaken, many non standard frontends for Modula-2, Modula-3 and Pascal also use their own languages.

http://gcc.gnu.org/frontends.html

--
Paulo

On Feb 28, 2013 9:36 PM, "pjmlp" <pjmlp@progtools.org> wrote:
>
> On Thursday, 28 February 2013 at 07:58:31 UTC, Jonathan M Davis wrote:
>>
>> 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
>
>
> GNAT is written in Ada.
>
> If I am not mistaken, many non standard frontends for Modula-2, Modula-3
and Pascal also use their own languages.
>
> http://gcc.gnu.org/frontends.html
>
> --
> Paulo

See my message above. The problem is not what language the frontend is written in, the problem is not requiring to interface to the gcc backend from the parts that are written in D.

Regards
-- 
Iain Buclaw

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

On 2/28/2013 5:15 AM, Jacob Carlborg wrote:
> On 2013-02-28 08:48, Walter Bright wrote:
>
>> Curiously, there appears to be no copyright/license information.
>
> Should be the same as DMD uses.

Well, it should say. In fact, with the current copyright law which specifies the default as "copyrighted, and no license at all" it needs to or nobody can use it.

I know I probably come off as a ninny about this, but professional users will run screaming from any open source code unless it contains:

1. a copyright notice
2. a license
3. who owns the above

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?

Walter,

On Thu, 2013-02-28 at 14:46 -0800, Walter Bright wrote: […]
> I know I probably come off as a ninny about this, but professional users will run screaming from any open source code unless it contains:
> 
> 1. a copyright notice
> 2. a license
> 3. who owns the above

Not ninni-ish at all, very sensible. Of course it is not the professional users that worry about these things, it is their lawyers. Worse there is a whole collection of misunderstanding and misapprehensions, not to mention FUD, about the various well known licences.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder