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

"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

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