"dolive" <doliv...@sina.com> wrote in message news:j4f55s$1r9p$1...@digitalmars.com... > Looking forward to the resurrection ddmd. >
Yea, that would be really nice. I'm wondering if maybe the problem is that it needs a different approach. I suspect a big part of the reason it's stagnated is because it's difficult to update to new versions of DMD. I think what's needed is an approach where changes from DMD to DDMD are minimal. Plus a "staged" approach to maximize DDMD's usefulness while it's under development. This is what I have in mind: Stage 1: Create D bindings to access DMD's functionality (ie, tell it to do lexing/parsing/sematic-analysis on some source, and then access the AST). The actual implementation would just be DMD's original C++-based source. Any changes that may be needed in DMD's C++ source can be folded into the official DMD sources on github. Updating to new DMDs would be trivial in most cases. Stage 2: One-by-one, convert sections of the C++ code to D, but *without* D-ifying anything. The goal here is to keep the converted D source as close as possible to the original C++ source. Anything that hasn't been converted yet will just fallback to the original C++ implementation. Updating to new DMDs would hopefully be much easier than it currently is. Stage 3: If/when the core DMD team is ready to switch to D, then DDMD would become the new DMD and the code would finally get D-ified. Or, if DMD stays C++, this D-ification could be done in a separate experimental fork of DDMD (so that the D-ification doesn't get in the way of updating the mainstream DDMD to new DMDs).
