Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!decvax!ima!johnl From: johnl@ima.UUCP Newsgroups: comp.compilers Subject: Re: Yacc poll Message-ID: <666@ima.ISC.COM> Date: Mon, 17-Aug-87 13:03:22 EDT Article-I.D.: ima.666 Posted: Mon Aug 17 13:03:22 1987 Date-Received: Wed, 19-Aug-87 01:27:12 EDT Sender: johnl@ima.ISC.COM Reply-To: Steve Vegdahl Lines: 61 Approved: compilers@ima.UUCP Michael Condict writes: >The advantages of a hand-written parser include: >(1) Speed. >(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. Steve Vegdahl Computer Research Lab Tektronix Labs Beaverton, Oregon harvard!seismo!sun!tekchips!stevev -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request