recursive descent

johnl@ima.UUCP (John R. Levine)
7 Apr 86 21:04:58 GMT

          From comp.compilers

Related articles
recursive descent johnl@ima.UUCP (1986-04-07)
| List of all articles for this month |

Relay-Version: version B 2.10.2 9/12/84; site mit-prep.ARPA
Posting-Version: version B 2.10.2 9/18/84; site ima.UUCP
From: johnl@ima.UUCP (John R. Levine)
Newsgroups: mod.compilers
Date: 7 Apr 86 21:04:58 GMT
Article-I.D.: ima.180
Posted: Mon Apr 7 16:04:58 1986
Date-Received: 8 Apr 86 11:24:16 GMT
Originally-from: William McKeeman <ihnp4!decvax!wanginst!mckeeman>

I concur with the positive evaluation of recursive descent compilers
given by Bob Gray. There is one more point that should be made: when
you are building the parser "by hand" you can "cheat". The compiler
builder can do anything the implementation language allows. For
difficult projects this can make the difference between success and
failure. Examples: a lookahead of 3 in an especially sticky spot of
syntax; a recovery algorithm based on semantic information rather than
just syntax; diagnostics based on all that is known, including the
symbol table; etc. etc. etc.

There is a price: If you win the implementation race by hacking,
someone else will pay during the maintenance phase. Recursive Descent
compilers deteriorate with time, both because they have accomodated
complexity during construction and because just -anyone- can get in
there and twiddle it later.

W. M. McKeeman mckeeman@WangInst
Wang Institute decvax!wanginst!mckeeman
Tyngsboro MA 01879

Send submissions to: ima!compilers

ima is reachable as { ucbvax!cbosgd | ihnp4 | cca | bbncca | think |
uiucdcs | allegra | inmet | yale | harvard }!ima!...
Arpa mail may make it to ima!compilers@CCA-UNIX or ima!compilers@BBNCCA

Post a followup to this message

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