new frontend written in D

[Gor Gyolchanyan]

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 <un at known.com> 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, ...
>