Re: Some questions about recursive descent?

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Tue, 01 Mar 2022 08:01:24 GMT

          From comp.compilers

Related articles
Some questions about recursive descent? johann@myrkraverk.com (Johann 'Myrkraverk' Oskarsson) (2022-02-27)
Re: Some questions about recursive descent? gah4@u.washington.edu (gah4) (2022-02-27)
Re: Some questions about recursive descent? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-02-28)
Re: Some questions about recursive descent? anton@mips.complang.tuwien.ac.at (2022-02-28)
Re: Some questions about recursive descent? alain@universite-de-strasbourg.fr.invalid (Alain Ketterlin) (2022-02-28)
Re: Some questions about recursive descent? johann@myrkraverk.invalid (Johann 'Myrkraverk' Oskarsson) (2022-03-01)
Re: Some questions about recursive descent? anton@mips.complang.tuwien.ac.at (2022-03-01)
Re: Some questions about recursive descent? alain@universite-de-strasbourg.fr (Alain Ketterlin) (2022-03-01)
Re: Some questions about recursive descent? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-03-02)
Re:Some questions about recursive descent? xdpascal@xdpascal.com (Paul Robinson) (2022-03-05)
| List of all articles for this month |
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Tue, 01 Mar 2022 08:01:24 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 22-02-021 22-02-024 22-02-026 22-02-027
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="41624"; mail-complaints-to="abuse@iecc.com"
Keywords: parse, LL(1)
Posted-Date: 01 Mar 2022 17:38:47 EST

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>So I was wondering if people who create /recursive descent/ parsers for
>production compilers use such a table as an intermediary step, or not.


Gray doesn't. For finding out about conflicts, it just looks at the
nodes involved. E.g., for a|b, it produces a warning if both a and b
can produce epsilon, if the first sets of a and b are not disjoint,
and if a|b may produce epsilon and its first set and its follow set
are not disjoint.


>I don't know Forth, so I haven't done much more than take a cursory look
>at the Gray manual; but it certainly wouldn't surprise me if people used
>a skeleton generator, from [E]BNF grammar, and then filled in the
>details later.


Gray is not a skeleton generator. It takes an RRPG (regular right
part grammar, similar to EBNF) with actions, and produces an
executable parser (i.e., not as source code). You then run that
parser, you do not fill in the details later; you provide all the
details in the source code before you generate the parser.


BTW, an updated version of Wirth's book that I mentioned is available
online for free:
<https://people.inf.ethz.ch/wirth/CompilerConstruction/CompilerConstruction1.pdf>.
The sections of interest to you seem to be Section 4.1 and 7.2,
probably also 7.3.


>[ [...] In my experience most people writing RD parsers do this
>informally, e.g., to deal with left recursion in expressions you know
>that you eat the first token, then peek at the next token and eat it
>if you're in the correct rule, otherwise return and let the caller
>deal with it. If this seems like more trouble than it's worth, now
>you know why we use parser generators. -John]


Or you start with EBNF or RRPG where you can express repetition
without recursion, so left recursion is rare.


I happen to look at Exercise 7.2 at this moment, which suggests
another way to deal with difficulties:


|7.2. Where is the Oberon syntax not LL(1), that is, where is a
|lookahead of more than one symbol necessary? Change the syntax in such
|a way that it satisfies the LL(1) property.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/



Post a followup to this message

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