4.6.6 Operators and Operator Precedence
The operators are listed below in order of *decreasing precedence*.
...
• Logical operators:
NOT
AND
OR
Ok. It is not clear from the spec whether "decreasing precedence" is
between each bullet in the list or whether this is also within each
bulleted section. But from the BNF (and our parser), I'd take your
interpretation (e.g. "and" expressions are always grouped before "or"
is applied to groups). So then everything makes sense.
Beats me why the authors could not write it explicitly like this, but
anyways... http://java.sun.com/docs/books/tutorial/java/nutsandbolts/operators.html
And what about jjtGetParent()?
This is the correct method. Generated by JavaCC, so it looks ugly like
that, still that's the one.
So +1 for the patch.
Andrus
On Jan 24, 2010, at 1:11 PM, Andrey Razumovsky wrote:
On the last lines, I meant
a or b and c -- will translate to --> a or b and c, while
(a or b) and c -- will translate to --> (a or b) and c.
So brackets only when needed
2010/1/24 Andrey Razumovsky <[email protected]>
4.6.6 Operators and Operator Precedence
The operators are listed below in order of *decreasing precedence*.
...
• Logical operators:
NOT
AND
OR
So e.g.
a or b and c
equals to
a or (b and c)
Actually it's the same in any language, e.g. in Java.
currently our translator has no notion of brackets around
statements at
all. We could insert them everywhere (like in Andreas's patch) -
but it's
cleaner insert them only when needed. So
a or b and c -- will translate to --> a or (b and c), while
a and b and c -- will translate to --> a and b and c.
And what about jjtGetParent()?
2010/1/24 Andrus Adamchik <[email protected]>
As I said, I don't understand 'needBracket' logic.
Per Andreas's example, the parser already does the correct
grouping based
on user specified parentheses. So all we need to do is to eagerly
place "("
and ")" around each conditional node. So Andreas's patch was doing
the right
thing (of course it also needed handling of AND and NOT).
And that's what we are already doing for SelectQuery qualifiers.
Although
IIRC we have a "flattenning" algorithm to skip parentheses in
uniformly
joined 3+ term conditions.. Was that the intention of
'needBracket'?.
Andrus
On Jan 24, 2010, at 12:39 PM, Andrus Adamchik wrote:
Where does the notion of priority come from? Logically (and from the
spec) OR/AND/NOT all have the same priority.
Andrus
On Jan 24, 2010, at 12:02 PM, Andrey Razumovsky (JIRA) wrote:
Andrey Razumovsky updated CAY-1371:
-----------------------------------
Attachment: 1371.txt
Patch that fixes the issue. Not committing it just yet, because
I'm not
sure about patterns of expression processing. Is it correct to
call
jjtGetParent() ? If so, why isn't there a method with more
suitable name?
--
Andrey
--
Andrey
