Re: Yacc poll

> ... The two huge wins [of yacc] for me were that
> I knew that it would complain about any invalid input (unlike recursive
> descent where practically every line seems to be followed by "else
> syntax_error();") and that as people asked for their favorite featurettes, I
> could throw in the new syntax and know I wouldn't break existing stuff...


I half agree with this. The "else syntax_error();" objection is, I'm afraid,
completely bogus: it is quite possible to write a recursive-descent parser
with error recovery handled systematically and automatically in the scanner.
I've done it. The parser needs to supply a bit more information to the
scanner than usual, so the scanner can compare actual input with expected
input, but it's not hard to do and it works very nicely... much better than
error recovery in yacc, in fact. The parser always sees a syntactically
correct program, and hence never has to try to unwind the semantics after
discovering an error.


The part about ease of change, though, I agree with. Personally I tend
towards using recursive descent for "production quality" parsers for well-
specified languages, and yacc for experimental work (where the language
changes underfoot all the time) and doing quick jobs (where minimizing
development effort is the primary concern). The type of language is also
a consideration: programming languages tend to be easy to parse with
recursive descent -- C and Pascal in particular were *designed* that way,
and parsing C with an LR parser is a little tricky (not that it's trivial
with recursive descent, groan...) -- while arbitrarily-invented notations
are much easier to handle with the greater power of yacc.


Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
[I'd be interested in hearing what the recursive descent lexer feeds to the
parser when the input is something like a = b + ( ; -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.