Re: Generating a simple hand-coded like recursive descent parser

Robert A Duff <bobduff@shell01.TheWorld.com>
17 Dec 2006 22:08:37 -0500

          From comp.compilers

Related articles
[23 earlier articles]
Re: Generating a simple hand-coded like recursive descent parser chris.dollin@hp.com (Chris Dollin) (2006-09-25)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-09-26)
Re: Generating a simple hand-coded like recursive descent parser zebedee@zebedee.net (zebedee) (2006-09-28)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-09-28)
Re: Generating a simple hand-coded like recursive descent parser phaywood@alphalink.com.au (2006-09-30)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-16)
Re: Generating a simple hand-coded like recursive descent parser bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-17)
Re: Generating a simple hand-coded like recursive descent parser tommy.thorn@gmail.com (Tommy Thorn) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser gneuner2@comcast.net (George Neuner) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser chris.dollin@hp.com (Chris Dollin) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser ajo@andrew.cmu.edu (Arthur J. O'Dwyer) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser 148f3wg02@sneakemail.com (Karsten Nyblad) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser ik@unicals.com (Ivan A. Kosarev) (2006-12-19)
[16 later articles]
| List of all articles for this month |

From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 17 Dec 2006 22:08:37 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 06-09-029 06-09-042 06-09-048 06-09-060 06-09-078 06-09-093 06-12-064
Keywords: parse, C, Ada

Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:


> Tommy Thorn wrote:
>
>> to work, most people think that C is an LALR(1) language or simpler (*).
>
>> (*) It's not. The lexer has to know which names are types, otherwise it
>> becomes impossible to tell if the statement
>> x * y;
>> is a declation of a pointer to x or an expression multiplying x and y.
>
> A more practical example, found in this group already:
> a = (b)-c;
> is (b) a type cast, or an expression?
>
> Sorry, I don't remember who "invented" this fine example :-(


Has anyone ever tried to solve these C / C++ parsing problems without
"feedback"?


Ada has a seemingly similar problem. For example, "X(Y)" might mean
call function X passing actual parameter Y, or array indexing with X
as the array and Y as the index, or convert expression Y to type X.
It might even mean call parameterless function X, which returns an
array, and use Y as the index.


The typical solution in Ada compilers is for the parser to build a
tree that means "this could be any of ...", with X and Y as subtrees,
and then semantic analysis has symbol tables, so it knows what X is,
and changes that node into a "function call" or "array indexing" or
whatever is appropriate. (Note: X could be an overloaded name.)


My question is: can that technique work for the above C and C++
ambiguities? Does it make the problem easier or harder? Is the
answer different for C++ than for C?


- Bob


P.S. Why do you say that the "a = (b)-c;" ambiguity is more practical
than the "x * y;" ambiguity? They seem like more-or-less the same
thing, to me: the parser wants to know whether each identifier is a type
name.


Post a followup to this message

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