Related articles |
---|
recursive descent johnl@ima.UUCP (1986-04-07) |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.