Re: LEX and YACC, jeff & mutt

In article <1989Nov4.000444.5512@esegue.segue.boston.ma.us>, henry@zoo.toronto.edu writes:
> I can think of a couple of reasons in addition to the ones given. First,
> many non-Unix systems have C compilers but not lex or yacc; maximal
> portability requires minimizing reliance on support software. ...


As long as the distribution and maintenance site has yacc and lex,
it doesn't matter whether or not the target sites do. There is
no reason to distribute the source grammar; it suffices to
distribute the C parser that is produced.


> ... Second,
> probably not applicable in this case, there are a number of languages --
> C and Pascal for example -- which were designed with top-down parsing
> (e.g. recursive descent) in mind and are awkward to handle bottom-up. ...


This kind of evaluation is largely subjective. In my opinion, it
is much easier to produce an LALR(1) grammar for a language like
C or Pascal than it is to write a recursive descent parser.
Writing LALR(1) grammars is initially tricky, because it takes a
fair understanding to avoid ambiguities or know that they will be
resolved correctly. But once one catches on, it is as natural as
anything else. It took me about three weeks to prototype a
database query language whose syntax was C with extensions, using
yacc and lex to produce the front-end, and awk to make the backend.


To summarize, parser generators (in the right hands) have a
tremendous advantage over hand-rolled parsers in the speed of
development, conciseness, and maintainability. Hand-rolled
parsers (by the right authors) are more efficient and permit
greater flexibility in error handling.


Russell
[From turpin@cs.utexas.edu (Russell Turpin)]

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