On Thursday, 28 February 2013 at 17:04:24 UTC, Marco Leise wrote:
> 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

The biggest benefit I predict that will come from an effort like this, is the productive change that comes about when you "eat your own dog food".

--rt

Am Thu, 28 Feb 2013 18:44:31 +0100
schrieb Timon Gehr <timon.gehr@gmx.ch>:

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

That can only mean that you don't really know what it does in my opinion. Sure such a large code base accumulates duplicates since not everybody knows about all helper functions or copy and paste was the least intrusive bug fix somewhere, but you don't really believe that 94% of the front end are unnecessary, do you?

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

Ah, I see where the wind blows ;)

-- 
Marco

>> (* Knowing the guts of a front end means you can decide to add type system and syntax extensions for private use. :P)
>
> Ah, I see where the wind blows ;)

Or, even better, an extensible FE with commonly distributed extensions like the Haskell compiler. And, of course, an AST macro system and a pony ;)

No, scratch that, with a good macro system, we can have the pony.

On Thursday, 28 February 2013 at 05:32:37 UTC, Walter Bright wrote:
> 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.

So you're saying some of our dogfood is actually caviar then...

I would divide the caviar into two groups, manifest and hidden. The manifest caviar is the easiest to sell. Hidden caviar is the benefits which are unexpected by at least a portion of the D community. Each piece of hidden caviar therefore needs one or more champions.

Not that this is a perfect example, but the lexer being assembled by Brian and Dmitri seems to have a spark of the hidden caviar about it, lending weight to the "clean room" camp. The politics of "existing" versus "clean room" must be mastered because there's a lot of room for resentment there if the wrong choices are made, it seems to me.

One thing both "clean room" and "existing" have, or should have, in common is the test suite, which is probably a better spec than the spec is. Perhaps a method can be devised which makes it easy to divide and conquer the test suite.

On Thursday, 28 February 2013 at 07:34:11 UTC, Jacob Carlborg wrote:
[...]
> Long term goal:
>
> When the translation is done we should refactor the compiler/front end to be a library, usable by other tools.
>

Yes that would be awesome. It can make the exact same tool at least 10x more useful and versatile.

I'm a big fan of tools that allow plugins, so I would also like to see parts of the compiler be written as loadable plugins that can be swapped in/out with different versions, and also to allow the tool set to be extensible by anyone.

--rt

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

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

On 2013-02-28 20:28, Arlen wrote:

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

That sounds more like one needs to figure out the intent of the code and not just look at the exact syntax. An easy example. C++ supports multiple inheritance, D does not. Trying to emulate that will most likely cause a lot of problem. But the use case in C++ could just be interfaces.

-- 
/Jacob Carlborg

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

Thank you, Thomas Koch

On 03/01/2013 07:48 AM, Marco Leise wrote:
> Am Thu, 28 Feb 2013 18:44:31 +0100
> schrieb Timon Gehr <timon.gehr@gmx.ch>:
>
>> * 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.
>
> That can only mean that you don't really know what it does in
> my opinion.

I guess it (almost) implements the language. :)

> Sure such a large code base accumulates duplicates
> since not everybody knows about all helper functions or copy
> and paste was the least intrusive bug fix somewhere, but you
> don't really believe that 94% of the front end are
> unnecessary, do you?
>

I believe it is bloated. Maybe it's partly because it is written in C++.

> ...