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

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

If that were the correct interpretation, then '2'..'1' should be the same as '2'..'9' but:

perl -de 0
  DB<1> p join " ", '2'..'1'

  DB<2> p join " ", '2'..'9'
2 3 4 5 6 7 8 9
  DB<3>
[download]

So it appears that perl 5.6.1 incorrectly doesn't realize that '0' comes before '1' when you write '1'..'0' but gets it correct for '1' through '8' since '9'..'8' and others give empty lists.

Note that 5.004_01 gets '1'..'0' correct but incorrectly thinks 'c'..'b' is the same 'c'..'z' (as does v5.6.0). So this is apparently a poorly-tested corner of the code.

...As well as being misleadingly documented. I'm confident that the original intent was that things like 'c'..'a' would return the empty list. So the code and the documentation both need to be patched to make this clear.

Update: Note that perl 4.036 realizes that '1'..'0' is the empty list but incorrectly thinks 'w'..'c' is the same as 'w'..'z'. So by no means a new bug. (:

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

Ah! I see it now. So after all it is documented. I should have looked a few paragraphs down in perlop.

However, I still don't see this behavior as DWIM-ish. It just doesn't sound logical.

Thanks anyway.
/prakash