[XPATH30]: Proposed short-circuit boolean operators

Michael,

Please find response interleaved below.

> 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

It was my intention that the rule statement about equivalency (repeated 
below for convenience) would provide the clarity you are asking for 
here. In other words, the proposal was that s-and would behave exactly 
like the equivalent 'if' statement. The draft 10 spec already well 
defines behavior of 'if' from the point of view of observable errors, so 
by definition, this level of precise definition also applies to the 
proposal.

     The expression ...
       $a s-and $b
     ... is equivalent to ...
       if ($a) then $b else false()


> (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?

I concede that I don't have a strong case for these two new operators, 
but let me pitch a case anyway. Consider this task:

Let $seq be a sequence of integers. Our task is determine if the 
maximum of the sequence occurs within the first 3 members. One solution 
might be this expression...

   [1] if (exists( $seq)) then index-of( $seq, max( $seq))[1] le 3 else 
false()

Of course there are many ways to skin a cat, and others might be 
tempted to suggest better techniques that don't use the index-of() 
function, but let us say for argument's sake we ignore those. Under the 
proposal, we could alternatively express this as ...

  [2] exists( $seq) s-and (index-of( $seq, max( $seq))[1] le 3)

It is worth noting that we cannot safely put...

  [3] exists( $seq) and (index-of( $seq, max( $seq))[1] le 3)

There is nothing that one cannot currently do, that one could do with 
the proposal. So the whole case for the proposal rests upon making the 
subjective comparison of expression [1] to expression [2] and asking the 
question: Is [2] clearer to read and more natural to write than [1]?

Naturally, if I personally didn't answer that question in the 
affirmative, I would not have put the proposal. But I've learnt from 
StackOverflow that what appears more readable to me can be just the 
opposite for others. The merit of the proposal is subjective.

So, that is the case for the proposal in a nut-shell. Does it make a 
difference?

> Michael Kay
> Saxonica
> (personal response)

Received on Wednesday, 21 November 2012 02:19:34 UTC