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

"Derek M. Jones" <derek@knosof.co.uk>
24 Dec 2006 11:01:33 -0500

          From comp.compilers

Related articles
[10 earlier articles]
Re: parsing C and C++, Generating a simple hand-coded like cfc@shell01.TheWorld.com (Chris F Clark) (2006-12-22)
Re: parsing C and C++, Generating a simple hand-coded like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-22)
Re: parsing C and C++, Generating a simple hand-coded like derek@knosof.co.uk (Derek M. Jones) (2006-12-22)
Re: parsing C and C++, Generating a simple hand-coded like ik@unicals.com (Ivan A. Kosarev) (2006-12-22)
Re: parsing C and C++, Generating a simple hand-coded like derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2006-12-22)
Re: parsing C and C++, Generating a simple hand-coded like cfc@shell01.TheWorld.com (Chris F Clark) (2006-12-23)
Re: parsing C and C++, Generating a simple hand-coded like derek@knosof.co.uk (Derek M. Jones) (2006-12-24)
Re: parsing C and C++, Generating a simple hand-coded like cfc@shell01.TheWorld.com (Chris F Clark) (2006-12-24)
| List of all articles for this month |

From: "Derek M. Jones" <derek@knosof.co.uk>
Newsgroups: comp.compilers
Date: 24 Dec 2006 11:01:33 -0500
Organization: ntl Cablemodem News Service
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-076 06-12-078 06-12-086 06-12-091
Keywords: C, C++, parse

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++.


Post a followup to this message

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