Hexadecimal and binary literals

[ChristianGruen]

Without wanting to challenge our weekly burn-down chart too much, I wonder whether it would be a big deal to support hexadecimal and binary literals in XPath? Examples:

(: decimal :)     1, 255,
(: hexadecimal :) 0x1, 0X00Ff,
(: binary :)      0b1, 0B11111111, 

The main question is probably if it conflicts with the existing grammar?

[michaelhkay]

Related to issue #241. One of the issues here is with the sign bit. In languages with fixed-length integers, 0xFFFFFFFF means -1 because we know there are 32 bits; with a variable-length integer, that doesn't work, and it's going to throw people if we adopt the familiar syntax with unfamiliar semantics.

[ChristianGruen]

Related to issue #241. One of the issues here is with the sign bit. In languages with fixed-length integers, 0xFFFFFFFF means -1 because we know there are 32 bits; with a variable-length integer, that doesn't work, and it's going to throw people if we adopt the familiar syntax with unfamiliar semantics.

I would propose to do the same what I summarized in #241 (comment): Most languages (including JavaScript, Python, Perl, or PHP) interpret 0xFFFFFFFF as 4294967295, and it would be surprising to get -1 in XPath (even more because there’s no fixed 32 bit xs:integer limit). And if an XPath implementation uses 32 bits for xs:integer, I would expect 0xFFFFFFFF to be rejected with err:FOAR0002.

[innovimax]

This ticket if I'm correct is about changing how XPath parses number
#241 is more about adding few function in F&O or EXPath or ThinLayer:tm:

[ndw]

If we have functions to do the conversions, and I think we should, adding the ability to write literals in hex and binary seems unnecessary to me. The compiler can obviously evaluate parse-integer-or-whatever-we-call-it('01011101', 2) as, uh, 93 I think, at compile time so there's no actual difference between that and also allowing 0b01011101 except additional complexity.

[ChristianGruen]

I think it does make a difference, as it's much easier to write 0xF instead of parse-integer('0F', 16). Instead of using the function, I believe users would rather compute the decimal value in advance and use a comment to indicate the hexadecimal counterpart.

It's still helpful to have additional functions, as they allow you to interpret dynamic input.

[ChristianGruen]

I’m getting tenacious (I beg pardon), but I believe XPath and XQuery are the only languages I have worked with so far that don’t support hexadecimal/binary literals. If it turns out that the addition is more complex than I would hope, though, I agree we should focus on the existing to-dos.

[line-o]

I side with @ChristianGruen and am in favour of adding additional literals that are common to other programming languages.
I also have a use case: Function annotations in XQuery would benefit from the ability to have additional literal value types.

[rhdunn]

I would always interpret the hexadecimal/binary literals as unsigned/positive values -- more specifically as xs:integer values, which don't specify a given size outside of implementation defined limits. Note that this is in line with the existing decimal literals, which are also unsigned/positive xs:integer values per the Literals section of the specification:

The value of a numeric literal containing no "." and no e or E character is an atomic value of type xs:integer.

If the user wants a negative value, they can use -0xF like they can with -16. The XPath/XQuery grammar separates out unary minus/negation from the numeric literal construction.

[ndw]

Closed by #433