|Parser then Attribute Grammar for C++ firstname.lastname@example.org (2004-02-08)|
|Re: Parser then Attribute Grammar for C++ email@example.com (2004-02-12)|
|From:||firstname.lastname@example.org (Vidar Hokstad)|
|Date:||12 Feb 2004 11:31:23 -0500|
|Posted-Date:||12 Feb 2004 11:31:23 EST|
email@example.com (Dez Akin) wrote
> What I'm interested in is if its possible to do the parsing of C++ in
> stages, making a regular grammar for the lexer, a LL(k) grammmer for
> the first parser, and an attribute grammar to decorate the resulting
> syntax tree, or if the semantic ambiguities in C++ actually prevent
> such a clean layering.
Off the top of my head the main issue will proably be that without
tracking introduction of type names you can't know whether a legal
identifier is a variable or a type, and possibly a template name.
For instance, is "foo<a,bar>(5)" to be treated as a constructor call
of the template instance "foo<a,b>", or as two statements "foo < a"
and "bar > 5" involving the variables a and bar? You need at the very
least to know whether "foo" is a type name or not to be able to
resolve the amiguity.
To parse C++ without knowing type names you'd have to delay a lot of
error checking and be flexible about what you accept, potentially
having to rewrite the parse tree for constructs where you can't find a
meaningful generic representation.
I'd think the more common way of handling C++ would be to recognize
the few constructs that can introduce type names, and let your lexer
access that information to explicitly mark a token as a type name if
Return to the
Search the comp.compilers archives again.