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