The proposed syntax was in an early draft of XQuery and was removed because the semantics are so convoluted. To retain orthogonality, we have to allow any sequence of integers to be used as a predicate, and then we get issues about what happens when the integers in this sequence are not monotonically increasing or contain duplicates, and messy problems if the predicate is supplied in a form such as [1 to @max] where the value of @max depends on the context item. It's not hard to write [position() = 1 to 10] and I suggest we leave it that way.

However, there's another form of range predicate that would be very useful, namely selecting all items in a sequence up to (and optionally including) the first one that satisfies some condition: something like

$sequence [[from|after]] condition [[to|before] condition]]

including the possibility of

$sequence from position()=3 to position()=5

but more usefully things like

$sequence before self::h1

or

$sequence after self::h1 before self::h2

Really, I don't know how you can call the semantics convoluted. You've given the perfect syntactic expansion yourself:

$seq[1 to 10] === $seq[position() = (1 to 10)]

There isn't a problem with sequences with holes in - it still means the same thing.

>$seq[1 to 10] === $seq[position() = (1 to 10)]

For what class of predicates does this equivalence hold? Any predicate whose value is a sequence of integers? Does it have to be the same sequence of integers for every node in the sequence?

Or does it only apply to an expression written syntactically as a RangeExpr? That would be a horrible breach of orthogonality.

> For what class of predicates does this equivalence hold? Any predicate whose
> value is a sequence of integers? Does it have to be the same sequence of
> integers for every node in the sequence?

For any sequence of numeric values.

> Or does it only apply to an expression written syntactically as a RangeExpr?
> That would be a horrible breach of orthogonality.

Agreed.

>For any sequence of numeric values.

Does it have to be a sequence of numeric values for every item in the input?

$seq[if (f(.)) then number(@min) to number(@max) else is-married(.)]

I think the overloading of predicates is bad enough already without introducing this.

(In reply to comment #5)
> Does it have to be a sequence of numeric values for every item in the input?

No.

> $seq[if (f(.)) then number(@min) to number(@max) else is-married(.)]
> 
> I think the overloading of predicates is bad enough already without introducing
> this.

It might be slightly more complicated to evaluate, but it's actually extremely useful to users. The full semantics of a predicate expression "SEQ[PRED]" under this proposal could be expressed as such:

for $s at $p in SEQ
where
  typeswitch($s)
  case op:numeric+ return $p = $s
  default return fn:boolean($s)
return $s

This is not a very big departure from the present semantics:

for $s at $p in SEQ
where
  typeswitch($s)
  case op:numeric return $p eq $s
  default return fn:boolean($s)
return $s

>for $s at $p in SEQ
where
  typeswitch($s)
  case op:numeric+ return $p = $s
  default return fn:boolean($s)
return $s

Surely not? It depends on the type of PRED, rather than the type of $s. It must be something like this:

for $s at $p in SEQ
where
  typeswitch($s/(PRED))
  case op:numeric+ return $p = $s/(PRED)
  default return fn:boolean($s/(PRED))
return $s

(In reply to comment #7)
> Surely not? It depends on the type of PRED, rather than the type of $s. It must
> be something like this:
> 
> for $s at $p in SEQ
> where
>   typeswitch($s/(PRED))
>   case op:numeric+ return $p = $s/(PRED)
>   default return fn:boolean($s/(PRED))
> return $s

Err, yes - that was a mistake.

Assigning to future requirements per Working Group decision (https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Oct/0087.html).