RE: Precedence rules for QuantifiedExpr - OrExpr - AndExpr

> I was rather surprised by this comment, but looking at the way the spec 
is
> written, I can see how you came to this conclusion. 

So you see the issue being that "or" is at the same level as FLWORExpr, 
some, every, TypeswitchExpr, and IfExpr "Precedence Order" table? 

> I'm pretty sure the
> intent was that
> 
> some x in y satisfies a or b
> 
> should parse as
> 
> some x in y satisfies (a or b)

Yep.  As extra enforcement to this fact, here is the diagnositic results 
from the test parser.

some $x in y satisfies a or b
|QueryList
|   Module
|      MainModule
|         Prolog
|         QueryBody
|            Expr
|               QuantifiedExpr
|                  Some some $
|                  VarName x
|                  In in
|                  PathExpr
|                     StepExpr
|                        NodeTest
|                           NameTest
|                              QName y
|                  Satisfies satisfies
|                  OrExpr or
|                     PathExpr
|                        StepExpr
|                           NodeTest
|                              NameTest
|                                 QName a
|                     PathExpr
|                        StepExpr
|                           NodeTest
|                              NameTest
|                                 QName b


Quiz time:

for $x in baz return $x or for $z in yada return $z

What does this expression do, in terms of parsing?

Answer: it is a syntax error.

for $x in baz return for $z in yada return $z or $x

What does this expression do, in terms of parsing?

Answer: it parses just fine.

This is a resolved issue, and I think is goodness, but is a little 
confusing when looking at precedence issues.

-scott
public-qt-comments-request@w3.org wrote on 12/19/2003 12:15:42 PM:

> 
> I was rather surprised by this comment, but looking at the way the spec 
is
> written, I can see how you came to this conclusion. I'm pretty sure the
> intent was that
> 
> some x in y satisfies a or b
> 
> should parse as
> 
> some x in y satisfies (a or b)
> 
> I'm copying it to public-qt-comments so that it gets onto the list of
> last-call comments.
> 
> Michael Kay 
> 
> > -----Original Message-----
> > From: www-ql-request@w3.org [mailto:www-ql-request@w3.org] On 
> > Behalf Of Peter Coppens
> > Sent: 19 December 2003 15:49
> > To: www-ql@w3.org
> > Subject: Precedence rules for QuantifiedExpr - OrExpr - AndExpr
> > 
> > 
> > 
> > All,
> > 
> > Looking at the XQuery spec, I am somewhat surprised by the 
> > consequences of the precedence rules for QuantifiedExpr - 
> > OrExpr and AndExpr 
> > 
> > What I mean is:
> > 
> > Take the query
> > 
> > for $x in (1,2,3)
> > where 
> >   some $y in (1,2) satisfies 1 = $y and $y = 1
> > return $x
> > 
> > Which, I think, is equivalent to 
> > 
> > for $x in (1,2,3)
> > where 
> >   some $y in (1,2) satisfies (1 = $y and $y = 1)
> > return $x
> > 
> > But now take the query
> > 
> > for $x in (1,2,3)
> > where 
> >   some $y in (1,2) satisfies 1 = $y or $y = 1
> > return $x
> > 
> > 
> > Which, I think, is equivalent to 
> > 
> > for $x in (1,2,3)
> > where 
> >   (some $y in (1,2) satisfies 1 = $y) or $y = 1
> > return $x
> > 
> > I find that rather confusing.
> > 
> > So I guess I have the following questions 
> > 
> > (1) is the above interpretation correct?
> > (2) is this a deliberate choice and if yes, are there any 
> > motivations for that decision that can be shared?
> > (3) would it not be possible to add an extra level of 
> > precendence where the OrExpr comes to sit between 
> > QuantifiedExpr and AndExpr, or would that propagate to have 
> > other side effects?
> > 
> > Thanks,
> > 
> > Peter
> > 
>

Received on Friday, 19 December 2003 13:37:32 UTC