Are there any plans or is there already a project for writing DMD in D?

Nothing proves the stability of a compiler more than it being able to compile itself. And wouldn't it speed up the creation and maintenance of the compiler too?

..But then I found a message from Walter (18 jan '05):
> It wouldn't be hard to translate the DMD front end into D, but then it
> would
> be very hard to connect it to back ends like gcc's.

So that's the reason D's front-end (../dmd/src) is in C++: because it's using the C compiler's back end and that one's in C/C++?

And it's that interfacing D with C++ problem again. If DMD would decorate class members the same as DMC (using the same calling convention, etc.), would it then be possible to link a .d in a C/C++ project, like DMC?

Lionello.

Lionello Lunesu wrote:

> So that's the reason D's front-end (../dmd/src) is in C++: because it's using the C compiler's back end and that one's in C/C++?

If DMD was written in D, what would you use to bootstrap it with ?

And you would have all the woes of the current compiler, like
not being able to create shared libraries, missing debug info,
plain old bugs, and other things that make D yet unreleased...

No, I for one think it's a good thing that DMD front-end is in C++.

--anders

Lionello Lunesu wrote:
> Are there any plans or is there already a project for writing DMD in D?
> 
> Nothing proves the stability of a compiler more than it being able to compile itself.  And wouldn't it speed up the creation and maintenance of the compiler too?
> 
> ..But then I found a message from Walter (18 jan '05):
> 
>> It wouldn't be hard to translate the DMD front end into D, but then it would be very hard to connect it to back ends like gcc's.
> 
> So that's the reason D's front-end (../dmd/src) is in C++: because it's using the C compiler's back end and that one's in C/C++?

I'm guessing that for the time being, any project to write a D compiler in D would remain a separate project from DMD itself.  It could be designed to be linked with a D back-end, which would open up the potential for compilers to be written in D.

The obvious way to bootstrap D on a new platform would be to keep hold of the C++-written DMD until a better solution is found.  FTM, what does a new platform's first C compiler tend to be written in?

> And it's that interfacing D with C++ problem again.  If DMD would decorate class members the same as DMC (using the same calling convention, etc.), would it then be possible to link a .d in a C/C++ project, like DMC?

http://www.digitalmars.com/d/overview.html

"Features to Drop"

"#  Link compatibility with C++.  The C++ runtime object model is
just too complicated - properly supporting it would essentially imply
making D a full C++ compiler too."

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Anders F Björklund" <afb@algonet.se> wrote in message news:d1c3n4$1164$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>
>> So that's the reason D's front-end (../dmd/src) is in C++: because it's using the C compiler's back end and that one's in C/C++?
>
> If DMD was written in D, what would you use to bootstrap it with ?
>

The first 'DMD written in D' would be compiled with the latest C/C++-written version. Subsequent versions would be compiled with the previous build.

Unless I misunderstand what you mean by 'bootstrap'...?

> And you would have all the woes of the current compiler, like not being able to create shared libraries, missing debug info, plain old bugs, and other things that make D yet unreleased...
>
> No, I for one think it's a good thing that DMD front-end is in C++.
>
> --anders

Stewart Gordon wrote:

> The obvious way to bootstrap D on a new platform would be to keep hold of the C++-written DMD until a better solution is found.  FTM, what does a new platform's first C compiler tend to be written in?

Usually bootstrapped using assembler. Or cross-compiled, if available.

Side note:
I thought that D was written in plain old C first, because of the misleading .c suffix that Walter is using for the C++ source files...

--anders

Nick Sabalausky wrote:

>>If DMD was written in D, what would you use to bootstrap it with ?
> 
> The first 'DMD written in D' would be compiled with the latest C/C++-written version. Subsequent versions would be compiled with the previous build.

So would that mean that you had to keep *two* D front-ends around?


Just seeemed a bit strange to rewrite the compiler in a different language when it was just barely starting to work written in C++... ;-)

Especially when it would be more useful to update it to, for instance,
work with GCC 4.0; instead of just doing a work-a-like but written in D?


Probably could make for a fun experiment or something. Just thought
that there was more urgent things to do before that... Like "D 1.0"?

Or any other of http://www.prowiki.org/wiki4d/wiki.cgi?HelpDProgress

--anders

"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d1c2f3$109f$1@digitaldaemon.com...
> Are there any plans or is there already a project for writing DMD in D?
>
> Nothing proves the stability of a compiler more than it being able to compile itself. And wouldn't it speed up the creation and maintenance of the compiler too?
>
> ..But then I found a message from Walter (18 jan '05):
>> It wouldn't be hard to translate the DMD front end into D, but then it
>> would
>> be very hard to connect it to back ends like gcc's.
>
> So that's the reason D's front-end (../dmd/src) is in C++: because it's using the C compiler's back end and that one's in C/C++?
>
> And it's that interfacing D with C++ problem again. If DMD would decorate class members the same as DMC (using the same calling convention, etc.), would it then be possible to link a .d in a C/C++ project, like DMC?
>
> Lionello.


Historically, I think "version 2" or equivalent of various language compilers have been ported to and bootstrapped with the latest v1.x of the language and reference compiler because at that time both the language and compiler would be pretty stable.

Maybe what Walter has planned is to port both front-end and back-end of the compiler for v2.0? And that would open up trying more aggressive optimizations specialized for D w/o changing the C/++ backend which is specialized for those languages.

A branch strategy like that would make a lot of sense, IMHO.

As for the "..very hard to connect to backends like GCC's", I think what was being referred to there was that building a frontend for GCC relies on so many C headers, GCC specific build options, etc.. that doing the frontend in another language that isn't in the base bootstrap configuration would be pretty tough if not impossible. Again, a stable v1.x of the GDC compiler included in the base GCC distro. would make that much more straightforward. Heck, AFAIK the GCJ frontend is still written completely in C and that's been around for years.

- Dave

"Anders F Björklund" <afb@algonet.se> skrev i en meddelelse news:d1c3n4$1164$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>
> If DMD was written in D, what would you use to bootstrap it with ?
>
> And you would have all the woes of the current compiler, like not being able to create shared libraries, missing debug info, plain old bugs, and other things that make D yet unreleased...

I don't see any of these as show-stoppers. What you need is one stable implementation on one platform, then you can quite easily cross-compile if you accept to generate eg. C as intermediate code. It is my impression that the DMD implementation has become quite stable, and is up for the task. I don't see how shared libraries fit in, the level of debug information is adequate (on Windows at least (which is good enough)), and trouble with immature libraries is not really a problem for a compiler, as its dependencies on libraries are quite small.

> No, I for one think it's a good thing that DMD front-end is in C++.

It has been a natural place to start, but a move to D would IMHO be a natural evolotion, and a good proof of concept. Walter may have his reasons to keep the implementation in C++ for now. I can only guess on what they could be, but guesses would include:

    - other issues are deemed to have higher priority.
    - the interface to his backend isn't trivial.
    - he needs to make a living, and breaking the dependency on the backend
is not good for business
       (and definitely not a priority).

Anyway, who says only Walter can do it? As I remember, he has encouraged a project like this.

Regards,
Martin

Martin M. Pedersen wrote:

> I don't see any of these as show-stoppers. What you need is one stable implementation on one platform, then you can quite easily cross-compile if you accept to generate eg. C as intermediate code. It is my impression that the DMD implementation has become quite stable, and is up for the task. I don't see how shared libraries fit in, the level of debug information is adequate (on Windows at least (which is good enough)), and trouble with immature libraries is not really a problem for a compiler, as its dependencies on libraries are quite small.

True, just thought that it was more of a "D 2.0" thing to be doing ?

Like at least finalize the language specification before starting
a rewrite of the compiler for it in itself ? Maybe I'm a sceptic.

>>No, I for one think it's a good thing that DMD front-end is in C++.
> 
> It has been a natural place to start, but a move to D would IMHO be a natural evolotion, and a good proof of concept. Walter may have his reasons to keep the implementation in C++ for now. 

I'm glad that he did, and that he then decided to make it Open Source
so that the frontend could be ported to GCC backend and made portable.

If not, I wouldn't be using D myself, so for that I am thankful...

--anders

Anders F Björklund wrote:
> So would that mean that you had to keep *two* D front-ends around?

The one in C++ can be abandoned, if we agree to write the D front-end in
a subset of the language that can be compiled with both the C++ and the
new D front-end.

For the one, i would suggest not to rewrite anything into something
hastingly. Walter has quite a particular D-like style, so a tool could
be written to translate the compiler source into D, taking its
particularities in account. Regularly test it if it works, develop it in
parallel to the compiler, and when it's ready, just make a switch. Of
course this is only a very hypothetical suggestion because i bet noone
would volunteer. I know i won't.

> Just seeemed a bit strange to rewrite the compiler in a different language when it was just barely starting to work written in C++... ;-)
> 
> Especially when it would be more useful to update it to, for instance, work with GCC 4.0; instead of just doing a work-a-like but written in D?

Why should this be a problem? GCC backend, being written in C, can be
talked to from any language one can compile, when a compatible C
compiler exists. In fact, GNU Pascal frontend is written in Pascal, etc.

I think i recall Walter saying he wants to have D frontend written in D someday. However, it's definately not time yet now so i think we can pick up on this discussion when we are past the currently awaited milestones.

-eye