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

Hans-Peter Diettrich <DrDiettrich1@aol.com>
22 Dec 2006 01:08:33 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: Generating a simple hand-coded like recursive descent parser tommy.thorn@gmail.com (Tommy Thorn) (2006-09-18)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-16)
Re: Generating a simple hand-coded like recursive descent parser bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-17)
Re: Generating a simple hand-coded like recursive descent parser cfc@shell01.TheWorld.com (Chris F Clark) (2006-12-19)
Re: parsing C and C++, Generating a simple hand-coded like gneuner2/@comcast.net (George Neuner) (2006-12-21)
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: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: 22 Dec 2006 01:08:33 -0500
Organization: Compilers Central
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
Keywords: C++, C, parse

George Neuner wrote:


> I would think that it is always possible to delay categorizing an
> identifier until after parsing. The difficulty lies in designing an
> initial IR which incorporates the ambiguities in addition to the
> unambiguous canon IR.
>
> For example, in the case of "a = (b)-c", the parser could construct an
> AST like the following
[...]


IMO you disregard the amount of postprocessing, or error recovery
(backtracking), when the first assumption was wrong. Argument binding,
operator precedence, and more, might be different for typecasts and
binary "-" or other operators like "(". When a tree has to be
reorganized later, why construct an tree in the first pass at all?
Weren't a multi-level grammar the simpler approach to (such) ambiguities?


DoDi


Post a followup to this message

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