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

Robert A Duff <bobduff@shell01.TheWorld.com>
23 Dec 2006 13:37:30 -0500

          From comp.compilers

Related articles
[35 earlier articles]
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)
Re: Generating a simple hand-coded like recursive descent parser boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2006-12-23)
| List of all articles for this month |

From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 23 Dec 2006 13:37:30 -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 06-12-066 06-12-072
Keywords: parse
Posted-Date: 23 Dec 2006 13:37:30 EST

"Ivan A. Kosarev" <ik@unicals.com> writes:


> Robert A Duff wrote:
>
>> 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?
>
> What benefits you would like with this technique?


If two or more modules depend on each other for their proper operation,
then they are tightly coupled. Cyclic dependencies make software
harder to understand than non-cyclic, other things being equal, because
you can't understand each module independently.


Can I use lookahead and/or backtracking in my parser? I'd like to be
able to answer that question without understanding semantic analysis
(whether the parser is hand written or tool generated). And when
understanding semantic analysis, I don't want to have to understand
subtle timing issues about when exactly the parser calls
"get_next_token" relative to when typedefs are inserted in the symbol
table -- I want to assume that I'm handed a tree on a silver platter,
and I don't care how it was constructed.


As someone else in this thread mentioned, if you're writing a tool
that depends only on syntactic issues (e.g. a pretty-printer), it
would be nice to be able to write a parser without writing a semantic
analyzer.


- Bob


Post a followup to this message

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