Related articles |
---|
advice needed re: parsing C decl syntax toronto.edu!tarvydas@csri (Paul Tarvydas) (1986-12-06) |
Re: advice needed re: parsing C decl syntax harvard!rutgers!seismo!rochester!ken (SKY) (1986-12-08) |
Re: advice needed re: parsing C decl syntax ihnp4!tektronix!tekchips.TEK.COM!stevev (Steve Vegdahl) (1986-12-09) |
Re: advice needed re: parsing C decl syntax ihnp4!bobkat!pedz (Pedz Thing) (1986-12-10) |
Re: advice needed re: parsing C decl syntax steve@basser.oz (1986-12-10) |
Re: advice needed re: parsing C decl syntax ihnp4!utzoo!henry (1986-12-16) |
Newsgroups: | mod.compilers |
Date: | Sat, 6 Dec 86 11:45:19 est |
From: | Paul Tarvydas <toronto.edu!tarvydas@csri> |
I've always been under the impression that YACC and friends produce
code/tables which are somewhat worse than could be done with a hand-built
parser (ie. usually recursive-descent).
Recently, I've tried to parse the C declaration syntax using recursive-descent
and have found that it's a fairly difficult task. I find a need to delay
parsing decisions until much later in the parse. For example, you don't know
whether you're parsing a function definition until you've seen a left
brace - up to that point, it could be anything from a declaration of a
variable (up until the left paren) to an external function definition.
I'm still reluctant to use a straight LALR table parser for reasons of
(ahem) efficiency. Things like expressions & statements are wonderful
candidates for recursive-descent. Lists of thingies also fall out into
simple code:
thingie-list ::= thingie | thingie ',' thingie-list
turns into:
thingie ();
while (inputChoice (COMMA)) {
thingie ();
}
without the need for interpreting table entries.
Has anybody successfully married LR parsing with recursive-descent
techniques? Are there any other clean tricks/techniques I could use?
thanx,
Paul Tarvydas
Tarvydas-Sanford Controls Inc.
...{utcs|utzoo|...}!utcsri!tarvydas
[Well, actually, I've never seen a compiler where the parser was the
particularly slow part. More typically you get slowness either in character
processing in the lexer or else in slow table searches in the code gen.
If you insist, I see no reason why you couldn't define EXPR as a token in
the yacc parser and, in contexts where an expression is legal, sneak off to
an operator precedence or recursive descent parser. But I really don't see
the point. Yacc certainly has its problems, but excessively slow parsing has
never seemed to be one of them. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.