where <code>%%e%%</code> is an expression, the <code>%%ci%%</code>

are boolean expressions, the <code>%%pi%%</code>'s are patterns, and the

where <code>%%e%%</code> is an expression, <code>%%c%%</code>

a boolean expression, the <code>%%pi%%</code>'s are patterns, and the

<code>%%ei%%</code>'s are sequence expressions.

</p>

<p>

It works exactly as a standard SQL select expression, with the difference that relations (that is sequences of tuples) after the <code>in</code> keyword can here be generic sequences, and before the <code>in</code> generic patterns instead of just capture variables can be used. So the result is the sequence of all values obtained by calculating <code>%%e%%</code> in the sequence of environments in which the free variables of <code>%%e%%</code> are bounded by iteratively matching each pattern <code>%%pi%%</code> with every element of the sequence <code>%%ei%%</code>, provided that the condition <code>%%c%%</code> is satisfied.

In other words, the first element of the result is obtained by calculating <code>%%e%%</code> in the environment obtained by matching <code>%%p1%%</code> against the first element of <code>%%e1%%</code>, <code>%%p2%%</code> against the first element of <code>%%e2%%</code>, ...; the second element of the result is obtained by calculating <code>%%e%%</code> in the environment obtained by matching <code>%%p1%%</code> against the <i>second</i> element of <code>%%e1%%</code>, <code>%%p2%%</code> against the <i>first</i> element of <code>%%e2%%</code>,...; and so on.

</p>

<p>

Formally, the semantics of the select expression above is defined as:

</p>

<sample><![CDATA[

transform %%e1%% with %%p1%% ->

transform %%e2%% with %%p2%% ->

...

transform %%en%% with %%pn%% ->

if %%e%% then [%%e%%] else []

]]>

</sample>

<p>

A <code>select</code> expression works like a set of nested

<code>transform</code> expressions. The advantage of using select rather than

transform is that queries are automatically optimized by applying classical