Re: Range Expressions

Yes, that's correct.

A reminder that in an early draft, (5 to 1) meant (5, 4, 3, 2, 1), and the reason we scrapped that was that (1 to count($X)) gives a surprising result when $X is an empty sequence. You don't expect string-join(1 to string-length($s) ! " ") to give you two spaces when $s is a zero-length string.

We could make (A to B by C) (or indeed (A by C to B)) a ternary operator in which B can be less than A, but it might be confusing that the meaning is inconsistent with the existing binary operator (A to B), which we obviously can't change.

Michael Kay
Saxonica

> On 7 Dec 2020, at 15:17, Tomos Hillman <yamahito@gmail.com> wrote:
> 
> I guess there are also the special cases, which would ignore the 'by' completely:
> 
>  5 to 5 = (5)
>  5 to () = ()
>  () to 5 = ()
> 
> Where 5 could be any (allowable) value; I think these are how the construct works now, but please correct me if not!
> 
> _________________
> Tomos Hillman
> eXpertML Ltd
> +44 7793 242058
> On 7 Dec 2020, 14:42 +0000, Tomos Hillman <yamahito@gmail.com>, wrote:
>> I think the most natural syntax would be to interpret the 'direction' of the step by the order of arguments; for me that is implicit by use of the word 'to': I would (naturally) expect:
>> 
>>  5 to 1 by 1 = (5, 4, 3, 2, 1)
>>  1 to 5 by 1 = (1, 2, 3, 4, 5)
>>  1 to -5 by 1 = (1, 0, -1, -2, -3, -4, -5)
>>  1 to 5 by -1 = error
>> 
>> So that the 'by' argument is always positive.
>> 
>> Tom
>> 
>> _________________
>> Tomos Hillman
>> eXpertML Ltd
>> +44 7793 242058
>> On 7 Dec 2020, 14:19 +0000, Christian Grün <cg@basex.org>, wrote:
>>> I showed the proposed syntax (1 to 5 by -1) to a non-X(Path|SLT|Query)
>>> developer, and the immediate response was:
>>> 
>>> You must be wrong, it’s surely supposed to be: 5 to 1 by -1
>>> 
>>> I guess it’s too late to always start counting with the smaller value,
>>> or to even allow "5 to 1" for reverse counts. Michael initially
>>> proposed to place "by" ahead of "to" [1]…
>>> 
>>> 5 by -1 to 1
>>> 
>>> …and I wonder if it’s not the better choice?
>>> 
>>> [1] https://github.com/expath/xpath-ng/issues/22
>>> ____________________________________
>>> 
>>> On Tue, Dec 1, 2020 at 10:02 PM Dimitre Novatchev <dnovatchev@gmail.com> wrote:
>>>> 
>>>>> Apart from anything else, it loses the idioms in the current language that rely on a range being a sequence of integers,
>>>>> enabling familiar constructs such as x[position() = 1 to 10].
>>>> 
>>>> Well, there is nothing wrong with series of time periods in a total time range.
>>>> 
>>>> Maybe we can have a lifted overload of range, providing a function that, when applied on the provided as integers start, end and step, will produce the actual start, end and step for the actual range:
>>>> 
>>>> range($startBase as xs:integer,
>>>> $endBase as xs:integer,
>>>> $stepBase as xs:integer,
>>>> $provider as function(xs:integer) as item() )
>>>> as item()*
>>>> 
>>>> So, the provider() or better name, will convert the integers to whatever typed-data we need.
>>>> 
>>>> Thanks,
>>>> Dimitre
>>>