On Saturday, 16 January 2016 at 15:13:28 UTC, H. S. Teoh wrote:
I disagree. I think having the dmd itself (lexer, parser, etc.)
as a
library (with the dmd executable merely being the default
frontend) will
do D a lot of good.
For one thing, IDE's will no longer need to reinvent a D parser
for the purposes of syntax highlighting; they can reuse the
actual parser the compiler itself uses, and thus actually be
correct (whereas their own parser may actually only parse a
subset of D correctly). They will also be able to support
instant feedback as the user types in D code (highlight syntax
errors on the fly, etc.).
This will also help with writing various tools that operate on
D code, e.g., pretty-printers like dfmt won't need to roll its
own lexer/parser anymore. Many other tools also become possible
(automatic refactorings, function call tree analysis,
dependency analysis, etc.).
You could even use libdmd in your own D code, thus being able
to have
the equivalent of the `eval` available in many scripting
languages
(except that it will have native performance(!)).
The problem of dmd refactorings becoming public breaking
changes is not as big a problem if the public API is properly
designed. If the compiler code itself is refactored to
interface between its sub-components via cleanly-designed APIs
with proper encapsulations, I don't see that it will become
prohibitively difficult to minimize public API changes without
hampering compiler development efforts. This is the way to go
for better compiler code quality anyway, so even if libdmd
never happens, the code should *still* be refactored in this
way.
Besides, I don't think anyone is sanely suggesting that we
allow dmd source files to be free-for-all externally-importable
modules. The more likely scenario is that there will be a
clearly-defined external interface that is unlikely to change
much, whereas the implementation underneath is still free to be
changed, refactored, reorganized, rewritten, etc..
T
You're sort of making my point for me.
I fully agree about all the benefits of making the lexer, parser,
etc. available as a library.
HOWEVER, as you say, this would first require a large refactoring
of the code, to make it suitable for use as a library. Time spent
on that refactoring is time that could have been spent improving
the compiler in other ways.
D is short of development resources as it is; I think fixing the
many bugs in the compiler and fleshing out important complex
features like C++ inter-op is of more value to the language in
the long run.
Also worth mentioning, is that the SDC project was actually
designed from the beginning for the use you're advocating. I'm
sure deadalnix would love to have more help with that...
