Re: Yacc poll

malcolm@keilir.UUCP (Malcolm Cohen)
14 Aug 87 17:02:03 GMT

          From comp.compilers

Related articles
Re: Yacc poll decvax!utzoo!henry (1987-08-06)
Re: Yacc poll pase@ogcvax.UUCP (1987-08-04)
Re: Yacc poll steve@hubcap.clemson.edu (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)
| List of all articles for this month |

Newsgroups: comp.compilers
Date: 14 Aug 87 17:02:03 GMT
References: <634@ima.ISC.COM>
From: malcolm@keilir.UUCP (Malcolm Cohen)
Organization: University of Iceland (RHI)

In article <634@ima.ISC.COM> harvard!ames!ausmelb!ejp writes:
>I am presently involved in a discussion about compiler implementation,
>specifically the pros and cons of Yacc,
>and I would like opinions from other experienced compiler-writers.


Well, the Toolpack/1 parser was generated using Yacc (the output was munged
into Fortran though). Recursive-descent parsing was considered (1) probably
insufficiently powerful to parse Fortran's somewhat grubby syntax, and (2 -
more importantly) impossible since ANSI Fortran does not provide recursion.
"ad hoc" was *NEVER EVER* considered suitable for parsing Fortran - it was hard
enough to get the bugs out of the Yacc input code (~1500 lines).


My own experience with writing recursive-descent parsers is that it is easy
to provide error recovery far superior to the normal Yacc stuff (and which one
often sees in C compilers). Unfortunately this also depends on the syntax of
the language in question - if there is not much variety of input 'terminator'
symbols (e.g. ';', 'end' in Pascal) error recovery is hobbled anyway.


The only place where I would use ad-hoc methods by choice is in lexical
analysis, as this is probably simple enough to hand-craft decently. In lexing
Fortran one has either to hand-craft an ad-hoc lexer or use something more
powerful than regular expressions (vis. lex) - or sadistically leave it to the
parser-writer to tokenise 'DO' statements etc... Toolpack/1 used a
table-driven pushdown automaton with backtracking - ugh.


Thus Toolpack/1 took a similar approach to that of Stu Feldman with his f77
compiler - FORTLEX for the lexer, and YACC for the parser. I recommend that
anyone who is considering the use or not of Yacc to read his paper describing
his implementation experience (in the proceeding of some ancient SIGPLAN
conference - I think 1978). He recommends its use.


>There seem to be some standard objections to Yacc in particular, e.g.
> c. the incomprehensibility of the C output
Perfectly comprehensible - even when translated into Fortran!
> f. debugging difficulties
Certainly easier than with an ad hoc parser (except for very small languages).


>and some more general objections, e.g.
> g. generic objections to LR parsing
Well, if recursive descent (LL) is powerful enough without kludging the
grammar, I find it can provide a more convenient framework for the semantics
and error recovery - but only for a suitable target language (not COBOL).
In this case LR has no advantages over LL, and may even lose because of its
excessive power.
--
Malcolm Cohen mcvax!keilir!malcolm
Utgardar, Computer Centre, University of Iceland, Reykjavik
--


Post a followup to this message

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