|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 email@example.com (1986-12-10)|
|Re: advice needed re: parsing C decl syntax ihnp4!utzoo!henry (1986-12-16)|
|Date:||Tue, 16 Dec 86 16:20:24 EST|
> ... Doing [automatic error recovery] in a procedural recursive-descent
> parser requires passing recovery sets to each parsing procedure...
> This slows the parser (even when parsing a syntactically correct program),
> and increases the stack space requirements...
On the contrary, doing automatic error recovery in recursive descent does
not require this, although one particular error-recovery algorithm may.
(I would add that if you are implementing the usually-sparse recovery sets
as bitmaps and passing them by value, as one might all-too-easily do in
Pascal, it's not surprising that the result is slow and bulky.) Building
automatic error recovery into a recursive-descent parser is not difficult
or inefficient if you think hard and do it right; I speak from experience
with a C parser, not exactly a favorable case. While I tend to agree that
table-driven parsers are likely to be a lot smaller and possibly somewhat
faster, the *practical* differences in error recovery are not significant.
(Why was I doing recursive-descent parsing if I think table-driven is
better, you ask? Partly because of some of the nice practical conveniences
of recursive descent, partly because the particular project was supposed to
be highly portable and hence I didn't want to be dependent on a big parser
generator that I couldn't export freely. I tinkered with hand-generated
tables for a bit, and I think that approach could have been made to work
acceptably, but it was taking too long to get all the details right.)
Henry Spencer @ U of Toronto Zoology
Return to the
Search the comp.compilers archives again.