# [TF-LIB] IN operator

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Sun, 07 Feb 2010 20:42:50 +0000
Message-ID: <4B6F25CA.2000908@talis.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
```Proposal for the IN operator.

IN is a operator with the same precedence as EQ etc.

Syntax:
expr IN ( expr1, expr2, ....)
expr NOT IN ( expr1, expr2, ....)

e.g.

FILTER ( ?x IN ('a', 'b', 'c') )
FILTER ( ?x NOT IN ('a', 'b', 'c') )

(SQL has NOT IN and !(expr IN ( expr1, expr2, ....)) is clunky)

Semantics:

Evaluation is equivalent to writing out in long form:

IN ==>
expr =  expr1 || expr = expr2 || ...

NOT IN ==>
expr != expr1 && expr != expr2 && ...

That makes IN a special form like || and && already are.  The arguments
are not all evaluated first, then the operator itself called.  If the
result can definitely determined

8 IN (1, 2, 3) is false
9 IN (1, 2, 1/0) is error

1 IN (1, 1/0, 3) is true
1 IN (3, 1/0, 1) is true

because in SPARQL 1.0:
1 = 3 || 1 = 1/0 || 1 = 1
is true

8 NOT IN (1, 2, 3) is true
9 NOT IN (1, 2, 1/0) is error

1 NOT IN (1, 1/0, 3) is false
1 NOT IN (3, 1/0, 1) is false

because in SPARQL 1.0:
1 != 3 && 1 != 1/0 && 1 != 1
is false

The outcome of evaluation is independent of argument order.

Alternatives:

Alt 1: Strict function: the arguments are all evaluated first so any
error means the expression is an error.

1 IN (3, 1/0, 1) is error
1 IN (1, 1/0, 3) is error

but it does mean all arguments must be evaluated even if not needed.

Alt 2: Left-right evaluation:
If an error is encountered, the expression is an error
but the evaluation stops if true for IN or false for NOT IN is
encountered.  The order of the arguments now matters:

1 IN (3, 1/0, 1) is error
1 IN (1, 1/0, 3) is true

and it isn't a rewrite to || and = anymore.

I prefer the rewrite to "=" and "||" version.

Andy
```
Received on Sunday, 7 February 2010 20:42:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:59 UTC