Re: parsing C and C++, Generating a simple hand-coded like

Chris,


> However, if you look at the function prototype examples I supplied,
> one can easily see that one has nested ambiguities. That is: not only
> is the outer function prototype ambiguous, but nested in each
> parameter/argument is another set of ambiguities and potentially
> nested within them a third, fourth, and so on level of ambiguities.
> Thus, you get effectively an n-squared problem.


True, but not very common in practice.


    > Of course, if you are given an existing language and told to parse it,
> it is a little late to revisit that decision. The good news is that
> C++ and it's friends have already caused the parser generator writers
> to attempt to extend their reach with techniques like backtracking,
> PEGs, GLR, predicated parsing, etc. As a result, some of those
> languages can be parsed reliably.


I thought the 'good' news about C++ parsing was that language designers
have (re)learned the importance of having a grammar that is easy to
parse using existing tools.


I think the interest in GLR and its ilk is driven by researchers
interest in doing something new and now having the computing resources
to do it.


> Still looking at the title of this thread, I wouldn't hold out much
> hope for a simple hand-written recursive descent solution to such
> languages. Moreover, those who think they have such solutions are
> likely deluding themselves. I doubt they could prove their solution
> is correct to my satisfaction.


The latest version GNU C & C++ compilers both use recursive descent. In
my view this was a big mistake for C which will make it much harder for
third parties to figure out what syntax gcc actually supports. I know
at least one other major C++ vendor uses a recursive descent parser, so
perhaps there are some overriding advantages of parsing this way in C++.

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