Yes. Indeed the presence of more then one (unlimited amount) of back-ends would require the front-end to be very carefully designed and bug-free. And this will force the front-end to be a separate tool, which will generate a standardized semantically tagged AST, which in turn can be used by any back-end (DMC, GCC, LLVM, maybe even VC++ ...) to generate code or any development tool (automatic build system, editors, automatic code analyzers, ...). I think having an official reference front-end like that is much better, then having an official reference compiler, since it gives a lot more flexibility, while it doesn't complicate anything.
But then the age-old human resource problem arises. Will D community work on an official reference front-end while DMD is alive and full of bugs? I think not. And despite the fact, that I'd love to dedicate my time to make a good front-end, 1 developer is not nearly enough for that. It seems, like all the D's remarkable parse-ability is currently being wasted, since DMD's buggy front-end is indeed the ONLY existing D parser (i don't take into account the non-working ones, like Dil). Pity... On Wed, Sep 28, 2011 at 6:27 PM, Trass3r <[email protected]> wrote: >> But this example shows the path: >> Imho a new frontend would need to focus on non-compiler applications >> first, such as >> - auto-completion etc. for IDEs >> - rewriting tools >> (- doc generation) >> >> cause these don't require a full-blown semantic analysis and codegen. > > I think this strategy would also enforce a proper design since requirements > are much firmer especially in the IDE context, > e.g. performance, memory usage, no stdout, exception safety, ... >
