Re: Parsing Questions

"VBDis" <>
14 Jun 2002 15:24:46 -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: "VBDis" <>
Newsgroups: comp.compilers
Date: 14 Jun 2002 15:24:46 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG
References: 02-06-034
Keywords: parse
Posted-Date: 14 Jun 2002 15:24:45 EDT

  "Stefan Ewing" <> schreibt:

>a = b++ + c;
>b will be incremented after b + c has been calculated. But the only
>place to put the operator (it seems to me) is between "b" and "+".
>But doesn't this imply we should increment b *before* adding it to c?

You have understood the difference between the prefix and postfix
operators, b++ and ++b?

In C, C++ and Java an operator serves 2 purposes:

it can modify the underlaying object (left hand side in binary
operators), and it executes the operation and returns the result of
the operation.

The result of the postfix operator is the value of the variable/object
before the modification, whereas the prefix operator returns the value
after the modification of the object. You'll find more operators with
different operations and results, e.g. with the input/output operators
<< and >>.

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

In this case the array selection operator [] also should be handled as
a unary operator. IMO such a classification is acceptable only for a
special (non standard) definition of unary operators.

Typically the number of operands is used to classify operators as
unary, binary or ternary operators, and then the . operator clearly is
a binary operator.

When you consider the implementation of user defined operators
(overloading), then you'll find different operator names, and
consequently different implementations, for the prefix and postfix
increment operators. This difference also must be reflected in the
parse tree.

With regards to the interpretation of the parsed tree, and to the
implementation of the operators, also the "primary" operand is of
importance. With "primary" here I mean that one operand (object),
whose operator method is called in order to execute the
operation. This distinction allows to overload and redefine e.g. the
<< operator, which normally is a shift operator, but which becomes an
input operator when the leftmost operand is a stream object.

IMO both the operator precedence and the associativity (left/right)
must be considered, in order to find the primary operand whose
operator method then is used to execute the operation.


Post a followup to this message

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