Re: Recursive Descent Parser

Chris F Clark <world!>
22 Feb 2000 09:33:35 -0500

          From comp.compilers

Related articles
Recursive Descent Parser (Rasmus Anthin) (2000-01-09)
Re: Recursive Descent Parser world! (Chris F Clark) (2000-01-12)
Re: Recursive Descent Parser (2000-01-25)
Re: Recursive Descent Parser (Christian Stapfer) (2000-02-10)
Re: Recursive Descent Parser (Randall Hyde) (2000-02-12)
Re: Recursive Descent Parser (Michael Larson) (2000-02-22)
Re: Recursive Descent Parser (2000-02-22)
Re: Recursive Descent Parser world! (Chris F Clark) (2000-02-22)
Re: Recursive Descent Parser (Fred J. Scipione) (2000-02-23)
Re: Recursive Descent Parser (2000-02-27)
Re: Recursive Descent Parser (2000-02-27)
| List of all articles for this month |

From: Chris F Clark <world!>
Newsgroups: comp.compilers
Date: 22 Feb 2000 09:33:35 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 00-01-027 00-01-032 00-02-034 00-02-058 00-02-111
Keywords: parse, design

Unfortunately, I seen to have started a thread that won't die
in which Mike Larson asked:

> Hmm... I am wrtting a shading language compiler for Renderman.... I
> have been having some problems with the language and putting various
> work arounds in to fix problems with yacc.... If the language is
> small enough and I am comfortable with recursive routines, should I
> try the recursive decent approach first?

This gets generally to the heart of the issue. If you are designing a
language (extension), and you find that you are having trouble getting
your parser generator be it yacc, pccts, or whatever, then the chances
are that your language design is not thought out. With hand-written
recursive descent you won't even know that you have a problem, you'll
just get a language that has hidden quirks.

However, most languages that one designs should trivially be both
LL(1) and SLR(1). It's very simple to guarantee that, simply start
each new construct with a unique keyword and then follow that with a
list of items (and if there are optional items at the end, have a
unique closing keyword). Languages which follow that simple
prescription are usually easy to parse and easy for readers to
understand since things are nicely unambiguous.

language: (decl-1 | decl-2 | ... | stmt-1 | stmt-2 | ...)* ;
decl-1: "var" id ("," id)* ":" type ";"
                                // var is unique starting keyword
                                                                  // : provides closing keyword to id list
                if-stmt: "if" cond "then" stmt ("else" stmt) "fi"
                                  // fi provides unique closing keyword to make else
// unambiguous

It's a little more subtle if you are writing a compiler for a language
whose grammar is already defined, as it may already have quirks that
you just have to implement, and then hacks to your parser generator or
using recursive descent is more defensible (in my opinion). In such
cases, asking in this forum will often get advice from people who have
solved the same problem before.

Hope this helps,

Chris Clark Internet :
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
Web Site in Progress: Web Site :

Post a followup to this message

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