Re: Parsing Questions

"Joachim Durchholz" <>
14 Jun 2002 15:20:10 -0400

          From comp.compilers

Related articles
Parsing questions (Rasmus Anthin) (2000-01-06)
Parsing Questions (Stefan Ewing) (2002-06-13)
Re: Parsing Questions (Michael J. Fromberger) (2002-06-14)
Re: Parsing Questions (Ian Wild) (2002-06-14)
Re: Parsing Questions (Joachim Durchholz) (2002-06-14)
Re: Parsing Questions (Richard C Bilson) (2002-06-14)
Re: Parsing Questions (VBDis) (2002-06-14)
Re: Parsing Questions (Stefan Ewing) (2002-06-17)
Re: Parsing Questions (Stefan Ewing) (2002-06-17)
| List of all articles for this month |

From: "Joachim Durchholz" <>
Newsgroups: comp.compilers
Date: 14 Jun 2002 15:20:10 -0400
Organization: Compilers Central
References: 02-06-034
Keywords: parse
Posted-Date: 14 Jun 2002 15:20:10 EDT

Stefan Ewing wrote:
> How can the postfix increment/decrement operators in C, C++, and Java
> be represented in a parse tree? For example, if we have the
> epxression
> a = b++ + c;

The parse tree for this would be

      / \
.++ c

(.++ indicating the postfix ++; you'd have different encodings for
prefix and postfix ++.)

> b will be incremented after b + c has been calculated.

Nearly, but not quite.
The .++ operator should return the value of b, then increment b. (This
may sound nonsensical, but on an implementation level, functions can
prepare the return value, do a few other things, and then actually return.)

> Also, how should one represent the Java field access operator (.) in
> a parse tree? At first glance, it seems like a binary operator to
> me (given the object name and the field name, a memory address is
> returned), but one operator precedence chart I saw online shows . as
> a unary operator.

The chart is wrong (there's always the possibility of a typo after all),
or it is based on a grammar that doesn't follow the normal operator
precedence patterns (e.g. if the grammar defines an access path as a
sequence of "access elements", each element being a name prefixed with a

This is not an official statement from my employer.

Post a followup to this message

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