So... let's document dmd

[H. S. Teoh via Digitalmars-d]

On Sat, Jan 16, 2016 at 08:35:40AM +0000, tsbockman via Digitalmars-d wrote:
> On Saturday, 16 January 2016 at 07:52:11 UTC, Jack Stouffer wrote:
> >dmd is now in D; theoretically that should allow for other projects
> >to import from it like a normal D project. So why not make all of the
> >ddmd modules available from any code that is complied with it, i.e.
> >just like Phobos?
> >
> >The parser was just an example, there are any number of things that
> >one could use from the code base.
> 
> That would be cool in theory, but it would likely become a major drag
> on development of the compiler itself.
> 
> Once you start promoting the compiler's internals as part of the
> standard library, you can expect sooner or later that pressure will
> mount to bring them up to the same high standards of API design and
> stability as Phobos.
> 
> While this process would be beneficial to the overall quality of the
> DMD code being exposed, it would also turn internal refactorings into
> public breaking changes. I really doubt that's a good trade-off at
> this point in DMD's development.

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

-- 
BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL