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) |
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/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.