Re: $a++ allowed by $a is not ! why?
by jeffa (Bishop) on Aug 30, 2003 at 16:42 UTC

Yep. Bummer, eh? From the perlop docs:
The autoincrement 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
"/^[azAZ]*[09]*\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'
The autodecrement operator is not magical.
UPDATE:
Sorry for not saying this originally ... but i have no
idea why the autodecrement 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
autoincrement operator magical.
jeffa
LLLLLLLLLLLL
RRRRRRRRRRRR
BBBBBBBB
HHHHHH
(the triplet paradiddle with highhat)
 [reply] [Watch: Dir/Any] [d/l] [select] 

print 0..9,"\n";
You get 0123456789. Now try the following code:
print 9..0,"\n";
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 descendingvalue 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  [reply] [Watch: Dir/Any] [d/l] [select] 

"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;
jeffa
LLLLLLLLLLLL
RRRRRRRRRRRR
BBBBBBBB
HHHHHH
(the triplet paradiddle with highhat)
 [reply] [Watch: Dir/Any] [d/l] 

 [reply] [Watch: Dir/Any] 

my $a = "a";
$a ;
print $a, "\n";
Abigail  [reply] [Watch: Dir/Any] [d/l] 



Re: $a++ allowed by $a is not ! why?
by demerphq (Chancellor) on Aug 30, 2003 at 23:15 UTC

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[AZaz]*[09]*\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
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.

demerphq
_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
}
 [reply] [Watch: Dir/Any] [d/l] [select] 

(what the correct name for this? commutable?).
commutativity involves only one operation.
$a + $b = $b + $a
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:~>
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[AZ]*[09]*\z/ > /\A[AZ]*[09]*\z/
++: /\A[az]*[09]*\z/ > /\A[az]*[09]*\z/
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. :)  [reply] [Watch: Dir/Any] [d/l] [select] 

Modern algebra would say that although ++ is onetoone,
it is not onto. As such, it is not a permutation, since
a permutation is defined as a onetoone 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 onetoone,
because the inverse of a onetoone function is onto
and vice versa, but the inverse of a function that is
not onetoone is not onto and vice versa. Some people
strongly prefer to avoid dealing with functions that
are not onetoone. Of course you could redefine the
domain of  so that it is onetoone, 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 "welldefined" to refer
to a feature that can be implemented and meet most
reasonable expectations. Applying the magic extension
to  would probably not be considered welldefined.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b>()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;>();print$/
 [reply] [Watch: Dir/Any] [d/l] 




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...
}
 [reply] [Watch: Dir/Any] [d/l] 


Re: $a++ allowed by $a is not ! why?
by broquaint (Abbot) on Aug 30, 2003 at 17:08 UTC

The autodecrement operator doesn't work on strings as it was decided that the behaviour for decrementing below the likes of 'a' would be undetermined, and therefore was not implemented.
HTH
_________ broquaint  [reply] [Watch: Dir/Any] 
A reply falls below the community's threshold of quality. You may see it by logging in. 
Re: $a++ allowed by $a is not ! why?
by cchampion (Curate) on Aug 30, 2003 at 17:13 UTC

 [reply] [Watch: Dir/Any] 