On 10/02/2014 20:32, Adam Wilson wrote:
Not having an IDE is more tangential, but no less important. Here we
have two integrations with popular IDE's, Visual Studio and Mono.
However, these integrations suffer from the lack of tooling for D. DMD
can't be used as libary, so these integrations have had to produce their
own parsing engines and they are always behind DMD itself so they never
parse the current DMD language quite correctly. This means that you
can't turn on the really cool features that we in the C#/Java community
have become used to. D's integration with IDE's is similar to the
situation with IDE integration for C++. Yes D is easier to parse than
C++, but since we can't use the canonical parser, we don't have any
parsers that match D in it's current form so the AST's are almost always
broken or plain incorrect.
Building a new IDE won't solve this problem. Here we need to focus on
building better tools for D, turning DMD itself into a library or
Compiler-as-a-Service in the current lingo, since libraries are now
"services". D needs to make great strides in tooling to be relevant, we
need first-class debugging, and they need to support more than the
terminal. We need D as library, we need better IDE integrations. We need
a broader standard library. We need more bindings for existing
libraries. We need more new libraries (like the Aurora library I am
working on).
Once you have a complete D parser (as all the major D IDEs have now),
it's easy to keep it up to date, since the new language syntaxes are
few, and easy to implement.
The real problem is semantic analysis (anything from code completion, to
error/warning reporting, etc.). That's the hard thing to implement (as
it's so extensive), to keep up to date, and to be full-feature and not
just limited.
There is not a chance in hell DMD would sucessfully be adapted for these
purposes. Maybe as fork, but not as the main stream. Even as a fork I
hardly see it happening (The Descent IDE went with this route but it the
semantic engine was buggy and quickly became very hard to maintain.) The
reasons are manyfold and I'm not going into detail, but suffice to say a
semantic engine for an IDE needs to be prepared to run in an
interactive/deamon mode to have a decent performance, not in batch (run
once) mode like a compiler. This adds several constraints and
requirements to the semantic engine architecture, something that DMD is
not prepared to. It would take a large engineering effort to adapt it to
that, and crucially, Walter would have to be involved, but he has his
hands full already.
A better approach for the D situation, is having a semantic engine done
from scratch, adapted for IDE use. With that in mind, a project like DCD
is very interesting and promising, although still a significant effort.
--
Bruno Medeiros
