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

Ivan Boldyrev <boldyrev@cgitftp.uiggm.nsc.ru>
19 Dec 2006 01:06:28 -0500

          From comp.compilers

Related articles
[30 earlier articles]
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)
Re: Generating a simple hand-coded like recursive descent parser boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser walter@bytecraft.com (Walter Banks) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser cfc@shell01.TheWorld.com (Chris F Clark) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-22)
Re: Generating a simple hand-coded like recursive descent parser bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-23)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-23)
[1 later articles]
| List of all articles for this month |

From: Ivan Boldyrev <boldyrev@cgitftp.uiggm.nsc.ru>
Newsgroups: comp.compilers
Date: 19 Dec 2006 01:06:28 -0500
Organization: this field is intentionally left blank
References: 06-09-029 06-09-042 06-09-048 06-09-060 06-09-078 06-09-093 06-12-064 06-12-066
Keywords: C, parse

On 9692 day of my life Robert A. Duff wrote:
> 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.


These operations are very close and they syntax is absolutely same.
And even some optimizations can be performed without distinguishing
them.


> The typical solution in Ada compilers is for the parser to build a
> tree that means "this could be any of ..."...
>
> 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?


Type declarations and arithmetic expressions are different: you can
use +, -, /, && etc in arithmetic expressions but you cannot do it in
type declarations. If we just "glue" declarations and expressions, then
parser will accept programs like this:


typedef int b;


...
a = (b+k)-c;


Semantic analysis, of course, can detect such errors, but it I don't
think it is easier than "feedback" parsing.


--
Ivan Boldyrev


                                                                                                        Чуешь "Тайд", чуешь?


Post a followup to this message

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