abakus%uklirb@unido.uucp (AG Hartenstein-UNI KL-FRG) (02/12/88)
I am looking for a parser-generator, which generates recursive-descent parsers
in PASCAL. Some time ago I saw a note about such a program named LILA, which
has been implemented at the Katholieke Universiteit Leuwen.
If anybody knows which person I have to contact to get this program, I would
be very thankful, if he would mail me the adress.
If you know about other parser-generators, which work in the same way, I
would be interested in information about these systems, too.
Many thanks in advance,
Michael Ryba
Dipl.-Inform. Michael Ryba phone: +49 631 205-2892
Kaiserslautern University e-mail: abakus%uklirb@unido.uucp
Dept. of Computer Science
P.O. Box 3049
D-6750 Kaserslautern, F.R.G.
[At the risk of much flamage, I'd be interested in comments about why one
might prefer an R.D. parser generator to an LR one. We've beaten error
recovery to death, unless someone has something genuinely new. -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestirving@cgl.ucsf.edu (Irving Reid) (02/26/88)
In article <887@ima.ISC.COM> the moderator remarks: >[At the risk of much flamage, I'd be interested in comments about why one >might prefer an R.D. parser generator to an LR one. We've beaten error >recovery to death, unless someone has something genuinely new. -John] One of my reasons for choosing R-D parsers is the ease of writing semantics using full attribute handling. I have some ideas about how a lazy programming language (like Miranda) might allow inherited attributes in an LR parser, but until that day I'll stick to R-D for anything that has relatively tricky semantics (read this as: anything much beyond creating a parse tree) - irving - [From blia.UUCP!irving@cgl.ucsf.edu (Irving Reid)] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!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
scott@BBN.COM (Michael Scott) (03/18/88)
| [At the risk of much flamage, I'd be interested in comments about why one | might prefer an R.D. parser generator to an LR one. We've beaten error | recovery to death, unless someone has something genuinely new. -John] Let's tackle the easy question first: why might one prefer an LL parser to an LR one. Answer: (1) because the table sizes are a lot smaller (2) because many people find the parsing technique a lot more intuitive (3) because it lets you put action routines anywhere you want to in your grammar (4) because it is amenable to very simple, high-quality, automatic syntactic error recovery (ala Fischer, Milton, and Quiring) Now the harder question: why might one prefer recursive descent [John's note was in response to a request for tools to build recursive descent parsers automatically]. Possible answers: (1) because you can look at the parser and really *see* what it's doing (2) because you can modify it even if you don't have the parser generator available (this might actually be a concern if you want to distribute the parser with source, but without the tools) (3) because it might conceivably run a little faster, just as "compiled" scanner tables (implemented with gotos) run faster than table-driven lex Of course, the recursive descent parser will be larger than the table-driven LL parser, and it won't support FMQ error recovery. -- Michael L. Scott University of Rochester (716) 275-7745 scott@cs.rochester.edu scott%rochester@CSNET-RELAY {decvax, allegra, cmcl2}!rochester!scott -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!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