W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2012

Re: Fwd: [XPATH30]

From: Michael Kay <mike@saxonica.com>
Date: Tue, 20 Nov 2012 13:24:11 +0000
Message-ID: <50AB847B.3090706@saxonica.com>
To: public-qt-comments@w3.org
In the majority of high-level languages, the operands of "or" and "and" 
can have side-effects, and defining the order of evaluation is therefore 
important. By contrast, in database query languages, performance can 
change by several orders of magnitude if an optimizer is given the 
maximum freedom to rearrange expressions (for example, choosing to use 
an index for one of the terms of a conjunctive expression). So two 
factors combine here: defining the order of evaluation is not necessary 
in the absence of side-effects, and it is undesirable in the presence of 
a powerful optimizer able to take advantage of indexes.

It's not clear how your proposed short-circuit rule would actually be 
expressed. The only observable effect would be on error behaviour 
(allowing the first operand to be used as a guard for the second). Would 
the processor be constrained to genuinely evaluate the first operand 
first, or merely to behave as it it did so from the point of view of 
observable errors? The detailed rules, as we know from the history of 
the whole "errors and optimization" section of the spec, could get very 
messy indeed.

Final point: if you want the working group to add two new operators, 
there's a need for much stronger justification than an unsupported 
statement that the current situation is "inconvenient". What do you need 
to do that can't currently be done?

Michael Kay
Saxonica
(personal response)

On 20/11/2012 04:54, sean@seanbdurkin.id.au wrote:
> In XPath 1.0 the boolean operators 'and' and 'or', behaved in common 
> like the majority of high level languages, in that short-circuit rules 
> applied. This is no longer the case in XPath 2.0 and the current draft 
> for XPath 3.0 . In XPath 2.0/3.0 it is implementation dependent 
> whether short-circuit applies or not. In my experience, I have found 
> this behavior inconvenient and would have preferred short-circuit rules.
>
> Assuming there was a good reason for disallowing short-circuit 
> (perhaps providing XSLT processors improved opportunities for 
> optimization?), I propose two new operators for XPath 3.0 . Both of 
> these operators are binary. The operands are boolean and the 
> expression result is boolean. I suggest that the proposed operands 
> would be helpful.
>
>
> op:s-and
> ========
>   Summary
>   -------
>   Performs boolean logical conjuctive with a short-circuit evaluation 
> rule.
>
>   Signature
>   ---------
>   op:s-and($arg1 as xs:boolean, $arg2 as xs:boolean) as xs:boolean
>
>   Rules
>   -----
>   The expression ...
>
>     $a s-and $b
>
>   ... is equivalent to ...
>
>     if ($a) then $b else false()
>
>
> op:s-or
> =======
>   Summary
>   -------
>   Performs boolean logical choice with a short-circuit evaluation rule.
>
>   Signature
>   ---------
>   op:s-and($arg1 as xs:boolean, $arg2 as xs:boolean) as xs:boolean
>
>   Rules
>   -----
>   The expression ...
>
>     $a s-or $b
>
>   ... is equivalent to ...
>
>     if ($a) then true() else $b
>
>
>
> Faithfully,
> Sean B. Durkin
>
>
>
>
Received on Tuesday, 20 November 2012 13:24:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:40 UTC