On 2/27/2013 4:57 PM, H. S. Teoh wrote:
How will this work with the continual stream of fixes that the current C++-based compiler is getting? I assume we're not just going to put DMD development on hold.
I've done many projects consisting of converting a medium sized code base from one language to another. The way that works is to do it incrementally. Incrementally means:
1. at each step (i.e. pull request) we will have a fully functioning D compiler that passes its test suite
2. there is no divergence in code bases because there is not a divergent code base.
Also, wouldn't this be a good time to review some of the current designs in DMD that may be hampering the full implementation of features that we'd like, such as discrepancies with TDPL, etc.? Would it make sense to redesign some of the code currently causing hard-to-fix issues as we're porting that part of DMD into D? It seems a bit counterproductive to simply transcribe the current buggy code into D, only to rewrite it later when (if) we finally get round to fixing it.
My experience chiming in - never ever ever attempt to refactor while translating. What always happens is you wind up with a mess that just doesn't work.
Finally, I think somebody has brought up the idea of "freezing" a particular subset of D that the D compiler can use in its own code, preferably a reasonably simple subset that is safe from breaking changes down the road (it would be pathetic if a breaking change causes the compiler to be unable to compile itself, because the source code uses a language construct that was later deemed to need redesign). As DMD is ported over to D, it should be restricted to using only this subset of the language, so that it does not hamper future developments of the language unnecessarily.
Experience chiming in - a successful model is that the HEAD is compiled by the previous official release of D.
