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.le...@gmx.de> wrote: > Am 24.10.2011, 09:55 Uhr, schrieb Gor Gyolchanyan > <gor.f.gyolchan...@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. >