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