So... let's document dmd

[tsbockman via Digitalmars-d]

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...