Re: Moving along...
[email protected] (Martin v. Loewis) 13 Aug 2002 22:18:09 +0200
| Newsgroups | gmane.comp.python.parser |
|---|---|
| Message-ID | <[email protected]> |
Jonathan Riehl <[email protected]> writes: > I personally don't like coupling semantics with grammar because it > makes both of them less readable, and constrains reuse of the grammar. I happen to like this very much. The coupling of actions *precisely* makes the grammar quite readable, as it gives yo a clue on how to trace processing. Reuse of the grammar is also not constrained - it is easy enough to remove the actions, and replace them with different actions. > For me the ideal example of this is the GNU C++ grammar. Some of us want > to write software engineering tools, not go straight to the GCC > intermediate language. In the case of g++, things are much more complicated: You cannot even parse C++ without intermediate semantic actions. The C++ lexer must have access to the symbol table, to properly classify typenames, template names, and other identifiers. Furthermore, the grammar is ambiguous, and the ambiguity must be resolved on a semantic level before parsing can continue. So those of you who want to write engineering tools may find that you have to parse a language different from C++, but similar enough so that the difference does not matter. In any case, I very much would like to see support for a bison-style input grammar, i.e. with interleaved actions. > What should the output of a Python parser generator be? Python > code? A parser object that could be serialized to multiple formats? With YAPPS, I found that outputting Python code is very useful, atleast if the Python code is readable - you then can easily trace the parsing with standard Python debugging techniques. I still fail to see the point of generalizing pgen - I made "pure Python" a requirement precisely because it ports to Jython easily, and also backports to older Python versions better. Regards, Martin