Migrating dmd to D?

Zach the Mystic reachBUTMINUSTHISzach at gOOGLYmail.com
Thu Feb 28 22:57:29 PST 2013


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.


More information about the Digitalmars-d mailing list