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.
