Re: How to handle operator of undefined associativity

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote
> BGB / cr88192 <cr88192@hotmail.com> wrote:


>> I guess I will add here that associativity only really makes
>> sense when binary operators are in use:
>> "3+4*5" => "(3+4)*5" or "3+(4*5)", ...


>> but, with a unary operator, there is only a single possible parsing:
>> the operator and the expression it operates on.


> That is true if you allow only prefix operators, or only
> postfix operators, but not if you allow both. Consider C:


> *x++ is *(x++) or (*x)++


> Where * and ++ are both unary operators.


<snip>
> [This isn't associativity, it's precedence. Humph. -John]


yes.


it could be clarified:
WRT associativity, there is only a single possible parsing for unary
operators, and it is still the expression the operator operates on.


however, it is still possible to have difference in precedence, which may
matter if mixing prefix and postfix operators.


however, a matter of precedence is not a matter of associativity.


"(*x)++" vs "*(x++)" is not a matter of if the parsing is left or right
associative, but rather, whether "*expr" or "expr++" has a higher
precedence.


in the case of C, postfix operators have a higher precedence than prefix
operators:
        primary expression;
        postfix operator;
        unary(prefix) operator;
        cast operator;
        multiplication;
        ...


now, an example of plain associativity:
"x+y+z" which would be "(x+y)+z" (left associative) or "x+(y+z)" (right
associative).


if one considers it, either one parsing or another is typically implied by
the implementation, as most languages don't have n-way operators (Lisp and
Scheme are a partial exception, however, even then a particular order is
followed internally, so the actual operation is itself left or right
associative WRT the group of operands).




AFAIK, left-associativity is most common for the generic arithmetic
operators (and I suspect is the way most people tend to see math, at least
when there are no explicit precedence rules).


for example: "2-3+4".
most people will likely evaluate this to 3, thinking internally "(2-3)+4".
I think most people would think it an error if the result were -5.




as a side note:
typically I don't like relying on the built-in precedence and associativity
rules when writing code when there are multiple "sane" interpretations, and
so tend to use extra paranthesis mostly to make my intention clear in cases
(even if there is only a single cannonical interpretation as per the
language standard).


for example:
if((x<3) && (x>(-50)))
        ...


many of these parens could be left out, leaving:
if(x<3 && x>-50)
        ...


however, I prefer the parens for sake of making intentions clear.
it is also extra relevant when using macros, since an expression could be
substituted in which could otherwise lead to an unintended parsing.


oh yes, and this bit of fun: "x<y>z". seems trivial enough, but in certain
well-known languages, there be dragons here...

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