character sequence constructor 'a' to 'z'

[liamquin]

character sequence constructor 'a' to 'z'

[Arithmeticus]

Why not simply 4.0's fn:characters("abcdefghijklmnopqrstuvwxyz")? Highly customizable, and transparent.

[michaelhkay]

Perhaps what we're searching for is a syntax like

$value[# RANGE #]

where

(a) If $value is an array, it operates on the array; if it is a string, it operates on the string; if it is a sequence (that is, any other sequence), it operates on the sequence.

(b) The syntax of RANGE allows us to select at least (i) any single item, (ii) any contiguous subsequence, (iii) any set of single items.

See also issues #149 and #816

[michaelhkay]

This digressed into a discussion of using operators such as [] to slice into a string. That's beyond the scope of the original issue. Having introduced char() taking a numeric argument, I don't think there's any further obvious improvement on the table, so I propose closing the issue with no further action.

[michaelhkay]

I'm not convinced we need to provide anything new here.

Firstly, I'm not sure what you want the semantics of ('a' to 'z') to be. You seem to be suggesting that you want all single Unicode characters whose codepoints are in this range, but you also hint that you might want single-character Unicode strings that are >= 'a' and <= 'z' in some collation (which is a different requirement), or that you might want all Unicode characters in some character category.

If the actual requirement is for unicode characters whose codepoints are in a range, then I think the expression provided is the right way to go. If that's a surrogate for some other requirement, then perhaps we need something new. For example we could certainly consider unicode-category('Latin') to return all characters in a unicode category or block.

[ChristianGruen]

In addition, we could allow both integers and strings as argument for fn:char, to be able to write…

 (65 to 90) ! fn:char(.)

Otherwise, people may be tempted to write…

 (65 to 90) ! fn:char(`#{ . }`)

[michaelhkay]

Yes, allowing an integer argument to fn:char seems reasonable.

[dnovatchev]

Just out of curiosity: Can we cast a string to a sequence (or an array) of single-character strings?

In C# a string is also an array of its characters and one simply writes myString[3] without any casts and this produces (a Char) the 4-th character of myString.

This is very convenient and it would be great to have something similar in XPath.

Maybe we could introduce a char type in XPath?

[Arithmeticus]

@dnovatchev see, new in 4.0, fn:characters

[michaelhkay]

We introduced the fn:characters() function to allow a string to be treated as a sequence of characters. Implicit casting to a sequence wouldn't work because a string is already a sequence of length 1.

[michaelhkay]

i’m not sure this is easily discoverable.

Making features "discoverable" is not something the specifications can do on their own; and there is always a problem that the more features we pack into the language, the harder it is for users to discover that they exist. We can do a fair bit by presenting examples of use cases, but in the end, the languages specs are a specification, not a user guide.

[dnovatchev]

We introduced the fn:characters() function to allow a string to be treated as a sequence of characters. Implicit casting to a sequence wouldn't work because a string is already a sequence of length 1.

Yes, but what I am proposing is not "implicit casting to a sequence".

It is implicit casting to an array.

We could even decide not to define such casting at all, just simply say that:

"abcdefgh"[3] is a shorthand for:

subsring("abcdefgh", 3, 1)

This is extremely nice and convenient - proven by my experience.

Easy to remember and use, twice shorter, less moving parts and much less error prone than the result of extending this shortcut.

[michaelhkay]

"abcdefgh"[3]

This expression, unfortunately, is legal since XPath 2.0, and returns an empty sequence.

A potentially viable alternative is to allow

"abcde"[1 ...]
"abcde"[2 ... 4]
"abcde"[3 ... 3]
"abcde"[... 3]

[dnovatchev]

"abcdefgh"[3]

This expression, unfortunately, is legal since XPath 2.0, and returns an empty sequence.

A potentially viable alternative is to allow

"abcde"[1 ...]
"abcde"[2 ... 4]
"abcde"[3 ... 3]
"abcde"[... 3]

I think we could do even better:

"abcd"(3)

And certainly, instead of using

substring("abcdefg", 2, 3)

We could have:

"abcde"[2 ... 4]

[ChristianGruen]

"abcd(3)"

Probably "abcd"(3) ?

"abcde"[2 ... 4]

What would (1 to 3, "abcde")[2 ... 4] yield?

[dnovatchev]

"abcd(3)"

Probably "abcd"(3) ?

Yes, thanks for catching this. Corrected in the referred-to comment.

"abcde"[2 ... 4]

What would (1 to 3, "abcde")[2 ... 4] yield?

2, "abcde"

[ChristianGruen]

What would (1 to 3, "abcde")[2 ... 4] yield?

2, "abcde"

Thanks. What would be the rules that lead to this result?

[dnovatchev]

What would (1 to 3, "abcde")[2 ... 4] yield?

2, "abcde"

Thanks. What would be the rules that lead to this result?

Sorry again. The result should be:

2, 3, "abcde"

The rules are that we have the sequence:

(1, 2, 3, "abcde")

And the deconstructor [2 ... 4] selects its subsequence starting with the second item and ending at the 4th item.

[ChristianGruen]

And the deconstructor [2 ... 4] selects its subsequence starting with the second item and ending at the 4th item.

Would ("abcde", 1 to 3)[2 ... 4] return 1, 2, 3 or "b", "c", "d"?

[dnovatchev]

And the deconstructor [2 ... 4] selects its subsequence starting with the second item and ending at the 4th item.

Would ("abcde", 1 to 3)[2 ... 4] return 1, 2, 3 or "b", "c", "d"?

1, 2, 3

[ChristianGruen]

$value[# RANGE #]

I assume it wouldn't be much shorter than

items-at($value, RANGE)   (: or :)
RANGE ! get($value, .)

Personally, I’d still be in favor of having $value[RANGE].

[dnovatchev]

Perhaps what we're searching for is a syntax like

$value[# RANGE #]

Could be even:

$value # RANGE #

or

$value <- RANGE