D compiler front end in Phobos (was: syntax definition language)

[Gor Gyolchanyan]

Right.
A generic parser can be created, but it should be extremely flexible,
because parsing is not a trivial task and every specific parser has
it's own tricks, that should be implemented when using the generic
parser.

We could also make tools, that would greatly aid in development of
parsers: state machines.
it would be great to implement a generic state machine, which could be
used with the generic parser to quickly and easily implement a very
specific parser.
Being able to use it at compile-time will be a tremendous improvement,
because then you could easily make a parser for your favourite
language and interpret it at compile-time to generate D code.

On Tue, Oct 25, 2011 at 4:59 AM, Marco Leise <Marco.Leise at gmx.de> wrote:
> Am 24.10.2011, 09:55 Uhr, schrieb Gor Gyolchanyan
> <gor.f.gyolchanyan at gmail.com>:
>
>> Making a general-purpose parser is the secondary issue. The primary
>> issue is having a D parser.
>
> I feel like we should make a list of feature that everyone wants the parser
> to support and go the better safe than sorry approach. It would be a pity if
> the frontend could do only one thing well, but not be used as a real
> compiler frontend for example.
>
> o  generates a representation that can be used by a backend: compiler
> o  internal representation can be updated incrementally: IDE
> o  understands multiple versions of D: "Gofix"
> o  can be queried about inferred stuff: pureness, auto, transitive
> attributes: IDE
> o  allows iteration over code elements or hooks/callbacks (e.g.
> onEnumDecleration(...)): DDoc, "Gofix"
>
> While there has been work done for a compiler I didn't look at the code to
> see if it is usable for any other use case.
>