Range operator weirdness?

[PrakashK]

In the node (tye)Re: Base36 numbers: speed and golf tye had a line in his code:

    @next{'0'..'9','A'..'Z'}= ('1'..'0','A'..'Z','0');

where he sets up a mapping of each of the base36 digits and their successor digits. What caught my eye was the part '1'..'0' on the RHS. At first I thought it might be a typo and tye really meant to type '9' instead of '0', but I immediately scolded myself for doubting tye (after all he has provided test data at the end of his program, so he surely must have tested it before posting, unlike me).

So, I looked in perlop, which says about the range (..) operator:

In list context, it returns an array of values counting (up by ones) from the left value to the right value. If the left value is greater than the right value then it returns the empty array.

Following this, '1'..'0' should result in an empty array. But that is not what I have seen.

>> perl -MO=Deparse -le '@x = (0 .. 9)'
@x = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9);

>> perl -MO=Deparse -le '@x = (1 .. 0)'
@x = ();

>> perl -MO=Deparse -le '@x = ("0" .. "9")'
@x = ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9');

>> perl -MO=Deparse -le '@x = ("1" .. "0")'
@x = ('1', '2', '3', '4', '5', '6', '7', '8', '9');

>> perl -le 'print "1" > "0" ? "yes" : "no"'
yes

It works as expected for the integer list case (returns the empty array), but in the other case of list of number strings, perl gives me a non-empty list even though, "1" > "0" is true. And, to top that, the resulting list stops short at '9'.

What am I missing?

/prakash

[xtype]

~# perl -MO=Deparse -le '@x = ("1" .. "00")'

Part of the magical auto-increment algorithm I imagine.

@x = ('1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '
+13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24'
+, '25', '26', '27', '28', '29', '30', '31', '32', '33', '34', '35', '
+36', '37', '38', '39', '40', '41', '42', '43', '44', '45', '46', '47'
+, '48', '49', '50', '51', '52', '53', '54', '55', '56', '57', '58', '
+59', '60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '70'
+, '71', '72', '73', '74', '75', '76', '77', '78', '79', '80', '81', '
+82', '83', '84', '85', '86', '87', '88', '89', '90', '91', '92', '93'
+, '94', '95', '96', '97', '98', '99');

~# perl -MO=Deparse -le '@x = ("1" .. "000")'
~# perl -MO=Deparse -le '@x = ("1" .. "0000")'

etc, etc.
Not a bug, but rather a feature?
Works with 5.6.0 ...

updated:
Also interesting

~> perl -MO=Deparse -le "@x=('00'..'99')"
# but:
~> perl -MO=Deparse -le "@x=('00'..'00')"
# and why does this not do what you would expect:
~> perl -MO=Deparse -le "@x=('00'..'090')"
# which does the same thing as
~> perl -MO=Deparse -le "@x=('00'..'009')"
~> perl -MO=Deparse -le "@x=('00'..'099')"
~> perl -MO=Deparse -le "@x=('00'..'090')"
~> perl -MO=Deparse -le "@x=('00'..'059')"
# but not if you start with something other than zero
~> perl -MO=Deparse -le "@x=('00'..'909')"

-xtype

[Ido]

The range operator (in list context) makes use of the magical auto-increment algorithm if the operands are strings. So the one character '1' is increased in its range. form perlop about Auto-Increment's magic: ...the increment is done as a string, preserving each character within its range...

[PrakashK]

>> perl -le '$x = "1"; print ++$x for (1..9)'
2
3
4
5
6
7
8
9
10

The autoincrement of "9" results in "10", not "0".

/prakash

[dragonchild]

Now I'm confused! (Not that this is all that surprising ...)

I thought that auto-incremement on characters would following the ASCII table. But, ord("0") is 48 and ord("1") is 49. ord("9") is 57 and chr(58) is ':'. Could someone explain what I'm not seeing?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[Sweeper]

I thought that auto-incremement on characters would following the ASCII table. But, ord("0") is 48 and ord("1") is 49. ord("9") is 57 and chr(58) is ':'. Could someone explain what I'm not seeing? The magical auto-increment does not use the whole ASCII table. It is limited to the 10 numbers, the 26 upper-case letters, and the 26 lower-case letters.

Furthermore, as said in the Camel book (page 91), the string must match /[a-zA-Z]*[0-9]*$/. That is, you can auto-increment file or file01, but not file01a.

Anyhow, you cannot get a : as the result of auto-increment, magical or not.

[petral]

It returns the empty list in 5.00503.   The above behavior is in 5.6.1; suspect a bug.

  p

[tye]

It was a typo. I didn't find it because the code worked in testing. I suspect a bug in Perl as well.

        - tye (but my friends call me "Tye")

[grummerX]

The Camel (3rd ed., pp. 104) mentions this behavior in a footnote:

If its operands are strings, the range operator makes use of the magical autoincrement algorithm discussed earlier.*

* If the final value specified is not in the sequence that the magical increment would produce, the sequence continues until the next value is longer than the final value specified.

See, it's not a bug, it's a "feature".

-- grummerX

[lzcd]

Maybe I'm missing something here but all of this leaves me just asking one question:

Why would anybody use "1" ... "0" over "1" ... "9" if they both give the same result?

Outside of it's confusing nature, is there a benifit in this idiom that I'm missing?