|Re: Yacc poll decvax!utzoo!henry (1987-08-06)|
|Re: Yacc poll pase@ogcvax.UUCP (1987-08-04)|
|Re: Yacc poll firstname.lastname@example.org (1987-08-11)|
|Re: Yacc poll ihnp4!m10ux!mncm000) (1987-08-14)|
|Re: Yacc poll malcolm@keilir.UUCP (1987-08-14)|
|Re: Yacc poll jbn@glacier.STANFORD.EDU (1987-08-16)|
|Re: Yacc poll decvax!utzoo!henry (1987-08-17)|
|Re: Yacc poll harvard!seismo!sun!tekchips!stevev (Steve Vegdahl) (1987-08-17)|
|Re: Yacc Poll harvard!rutgers!mcnc!ece-csc!mauney (1987-08-18)|
|Date:||17 Aug 87 10:03:22 PDT (Mon)|
|From:||Steve Vegdahl <harvard!seismo!sun!tekchips!stevev>|
Michael Condict writes:
>The advantages of a hand-written parser include:
>(2) Flexibility in error-reporting and recovery.
>(3) Ease of data allocation in the semantic code.
>(4) Flexibility in use of the parser.
>The only disadvantage of a hand-written parser that I am aware of is that, for
>an experimental language whose syntax is changing rapidly, the effort spent
>modifying the parser may be considerable. This is not a serious impediment
>for a programmer who is experienced with recursive-descent parsers, but is a
>consideration if the parser is to be maintained by programmers who have always
>done their parsers with canned generators like yacc.
I have used both recursive descent and parser generators; my experience is
that parser generators are far better. The following are advantages that
I see to using a LR parser generator.
1. Debugging of the grammar. If your grammar is ambiguous, a parser
generator will tell you about it. For a hand-written parser, such
an ambiguity would have to be discovered manually.
2. Time savings. Writing/modifying a grammar, rather than parsing code,
is much faster and less error prone.
3. Automatic error recovery. Contrary to Mr. Condict's claim above, LR
parsing is very well suited to nice error recovery--and it can happen
"for free"--i.e., with no work other than writing the grammar.
Although YACC has a poor error-recovery mechanism, there are other
parser generators that handle error recovery very nicely. I have yet
to see an error-reporting/recovery mechanism for a hand-coded parser
that is as nice as I've seen generated by a LR parser generator. And
the hand-coded ones have to be coded up!
4. Multi-language use. If your compiler-implementation language changes,
one can get new parsers by simply writing a new "back-end" for the
parser-generator and a new parser driver. With recursive-descent, you
have to rewrite all of your parsers.
5. Wider range of grammars. With recursive descent, one is limited to
LL grammars, which are less powerful than LR.
>To summarize with a controversial claim: parser generators are a classic
>example of a solution looking for a problem.
>... I do not find that is has saved
>me any significant amount of labor, certainly not enough to justify the
>restrictions it has put upon my parsers.
I have used YACC, as well as several other parser generators. YACC was
probably the least easy to use of any, but I'd still pick it in a second
over having to write a parser by hand. I liken the LR/RD parser
comparison as being similar to the HLL/assembly language comparison.
LR parsing lets you use an appropriate tool and get the job done in
a timely manner, while RD parsing forces the programmer to specify
everything at a low level.
Computer Research Lab
Return to the
Search the comp.compilers archives again.