Migrating dmd to D?

[Timon Gehr]

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.