The auto-increment operator has a little extra builtin magic to it. If you increment a variable that is numeric, or that has ever been used in a numeric context, you get a normal increment. If, however, the variable has been used in only string contexts since it was set, and has a value that is not the empty string and matches the pattern "/^[a-zA-Z]*[0-9]*\z/", the increment is done as a string, preserving each character within its range, with carry:

    print ++($foo = '99');      # prints '100'
    print ++($foo = 'a0');      # prints 'a1'
    print ++($foo = 'Az');      # prints 'Ba'
    print ++($foo = 'zz');      # prints 'aaa'
[download]

The auto-decrement operator is not magical.

UPDATE:
Sorry for not saying this originally ... but i have no idea why the auto-decrement operator is not magical. But, how often (japh's not included) do you need to decrement a string? Incrementing strings is a handy way to get a new value, say for an identifier. When you need a new id, just increment. I may not be right about this, but i am guessing that this was the movitation behind making the auto-increment operator magical.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

I can not say why -- isn't magical, but it occurred to me that the .. range operator only works going from little to big, and works much in the same way as ++ increments, and with similar magic.

Try the following example:

print 0..9,"\n";
[download]

You get 0123456789. Now try the following code:

print 9..0,"\n";
[download]

You don't get much of anything at all. Camel says, "The range operator (in a list context) makes use of the magical autoincrement algorithm if the operands are strings."

What isn't stated, but perhaps can be deduced, is that the range operator internally uses the autoincrement function, which when fed strings, behaves magically, and when fed numbers behaves normally. But the point is, the range operators don't use the autodecrement function.

It seems to me (and this is pure speculation) that the autoincrement operator was given its special magic so that the range operator can construct things like A..Z. Again, this is speculation, but .. needed to be able to handle A..Z, .. internally used the autoincrement function, so to make it easy, autoincrement was given magic so that the range operator could become a more useful operator, not limited only to numbers.

Now as for why the range operator doesn't enumerate descending-value lists also, that's another question, and I shouldn't speculate. ;)

Dave

"If I had my life to do over again, I'd be a plumber." -- Albert Einstein

"the autoincrement operator was given its special magic so that the range operator can construct things like A..Z"

This makes so much more sense. :) By the way, working around the lack of -- magic isn't so easy, but working around the .. limitation is, if you can spare the memory overhead for large lists:

print for reverse 1..99;
[download]

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Hello Jeffa,


Thanks for your reply. However, why is the auto-decrement operator not magical in nature?

regards,
Abhishek.

However, why is the auto-decrement operator not magical in nature?

Suppose it was, what would the following print:

    my $a = "a";
    $a --;
    print $a, "\n";
[download]

Abigail

I'm going to register what I consider to be the most serious reason why -- isnt implemented this way. Reversability. Consider that the rules say any string matching /\A[A-Za-z]*[0-9]*\z/. So this means that 'Zz9' incremented becomes 'AAz0'. Now, what happens when we decrement? Presumbly we should go from 'AAz0' back to 'Zz9'. So we need decrement to remove the leading character. All fine and good. So we decrement a bunch more and eventually get to 'z9'. Now we increment one, and get 'aa0'. So we then end up in the odd situation where -- and ++ are not reversable (++(--'Aa0')!='Aa0') (what the correct name for this? commutable?). It gets even odder, because if we contine down this path we get to '9' which again if we reverse course and increment leaves us at "10" and in the same problem as before but with different colors. And if we contine to decrement we go to -1 and etc as per normal numbers. But what happens if we decrement "A"? If we go to undef as one poster suggested we get a contradiction (in that --0 produces -1 but --'a' produces undef), and after we decrement undef again we get -1 (with a warning thrown in) so now its all a big mess.

++ Zz9   => AAa0
-- AAa0  => Zz9
-- aa0   => z9
-- Aa0   => z9
++ z9    => aa0
-- a0    => 9
-- 10    => 9
++ 9     => 10
-- 0     => -1
-- a     => undef
-- undef => -1
[download]

Given all this I can totally understand why -- isnt implemented. I don't think I would have a problem if this behaviour did occur, but I think its strange enough that I can see why it doesn't.

(what the correct name for this? commutable?).

commutativity involves only one operation.

$a + $b = $b + $a
[download]

and at least two operands which get "permuted". thus, it is pointless to ask for commutativity of an unary operation.

the problem is, ++ is not surjective.
or can you find a value for $z so that ++ $z is "Aa0"? no, you can't:

kabel@linux:~> perl
my ($z1, $z2) = qw/ z9 Z9 /;
print ++ $z1, ", ", ++ $z2, $/;
aa0, AA0
kabel@linux:~>
[download]

thus, ++ does not have any reverse mapping at all.
but if we only allow either lower case or upper case (not both mixed), the problem nearly disappears:


++: /\A[A-Z]*[0-9]*\z/ -> /\A[A-Z]*[0-9]*\z/
++: /\A[a-z]*[0-9]*\z/ -> /\A[a-z]*[0-9]*\z/
[download]

a problem is that "0" has no preimage.
or can you find a value for $z so that ++ $z is "0"? no, you can't. ;D

HTH hehe, finally i was able to apply some knowledge of last years mathematics. hopefully, i am correct. :-)

Modern algebra would say that although ++ is one-to-one, it is not onto. As such, it is not a permutation, since a permutation is defined as a one-to-one onto function from a set to itself.

-- OTOH (as it is currently defined) is theoretically a permutation over the set of all finite numbers, provided you run Perl on an architecture capable of storing and representing all numbers in that set. (In practice I am not aware of any such architecture, but nevermind.)

The logical conclusion is that if -- were made the inverse function of ++ it would no longer be one-to-one, because the inverse of a one-to-one function is onto and vice versa, but the inverse of a function that is not one-to-one is not onto and vice versa. Some people strongly prefer to avoid dealing with functions that are not one-to-one. Of course you could redefine the domain of -- so that it is one-to-one, but then you have a function on an apparently very arbitrary set (a set defined in terms of the range of ++ in fact), which could be considered "messy".

I don't know how much of this went into the decision, but I know that Larry knows some set theory, so it is entirely possible he considered this issue. It's also entirely possible that he just "felt" that applying the magic string extension to -- would be messy, without ennumerating all these points; sometimes people who design software for a living have a pretty good feel for which features would result in thorny issues. Sometimes they use the term "well-defined" to refer to a feature that can be implemented and meet most reasonable expectations. Applying the magic extension to -- would probably not be considered well-defined.

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

but if we only allow either lower case or upper case (not both mixed), the problem nearly disappears:

As long as you can mix numbers with letters the problem remains.

or can you find a value for $z so that ++ $z is "0"? no, you can't.

What about -1?

But thanks, some good links there. :-)


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

_________
broquaint

jeffa and broquaint have provided you with the theory.

Here's some practical fun with the auto-increment operator. Enjoy!