# [tmql-wg] Boolean Expressions (was: Re: Comments against TMQL draft 2006-02-22)

Robert Barta rho at bigpond.net.au
Sat Mar 10 23:34:30 EST 2007

On Sat, Mar 10, 2007 at 12:03:59PM +0100, Lars Heuer wrote:
> Ok. IMO the boolean expr. need some more explaining words.

I will add something to a tutorial/user guide. Not sure whether it fits into
the standard itself.

> Someone might get the impression that you mean with "non
> short-circuit", that every operant has to be evaluated even if the
> first operant evaluates to "false" in an ANDed expression. That is
> not meant (I hope ;)).

But it is EXACTLY what is meant :-) And it is good, here's why:

When a user writes

a & b

then the interpretation is 'pure' as it ALWAYS means the same as

b & a

In other words, there is never a situation in TMQL where there can be
a difference between the two. In other words, a TMQL processor can use
this as optimization. If it thinks it is cheaper to evaluate the
second operand first it can safely do so, without distorting the
meaning the user applies to this.

> With not short-circuit you mean, that the processor might evaluate
> the operants in a boolean expression in any order it likes. But once
> the proc. gets something that can be interpreted as false it can work
> with the "false"-value (in an AND expression).

Of course, if one of the operands evaluates to false, then it is not
necessary to evaluate the other.

This is all very different to, say C, where

a && b

NEVER allows the compiler to do anything clever. It ALWAYS has to
evaluate a before it does (maybe) b. Now, in low-level languages, such
as C and Jaaaaavaaaaa, you are close enough to bits and bytes to do
such optimization manually. In high-level languages (think XSLT,
XQuery, SPARQL, Haskell, ...)  there is more to be gained with
automatic optimization.

\rho