On Tuesday, 18 December 2012 at 21:30:04 UTC, Walter Bright wrote:
D is open source. There is little implementation cost to doing
a compiler for it. It's a solved problem.
Let me emit some doubt about that.
First, D is difficult to compile because of the compile time
features. DMD frontend is not the best piece of software I've
seen on an extensibility point of view.
Plus, if D is open source in its license, it isn't in its way of
doing things. When you drop functionality into master for reason
the community isn't even aware of, you don't act like in an open
source project. You'll find a huge gap between adopting a license
and adopt the cultural switch that is required to benefit from
open source.
Right now, it is painfully hard to implement a D compiler, for
various reasons :
- No language spec exists (and dmd, dlang.org and TDPL often
contradict each others).
- The language spec change constantly.
- Sometime by surprise !
- Many behavior now considered as standard are historical dmd
quirks, that are hard to reproduce in any implementation not
based on dmd.
- Nothing can be anticipated because goals are not publics.
- Sometime you'll find 2 specs (-property) for the same thing.
- Many things are deprecated but it is pretty hard to know which
one.
- It in unknown how to resolve paradoxes created by compile time
features.
- I can go on and on.
Right now only dmd based front end are production quality, and
almost no tooling exists around the language. You'll find very
good reasons for that in the points listed above.
A bytecode requires another spec to be written, and if you
think it's easy to make a conformant Java VM bytecode
interpreter, think again :-)
Nobody ever said that.
Yes, it is trivial. The only thing that is lost are local
variable names and comments.
You'll find tools that compact your whole project, loosing in the
process all names.
