HaloO, Michele Dondi wrote:
And yes: there are lots of languages having (e.g.) a ++ operator, mostly "derived" from C. But Perl's C<++> already allows an extended syntax wrt that of those other languages, that is: I'm not really sure, but I don't think that in C you can do (the equivalent of) C<($u*=5)++> - not that you need it that often, granted! But it is "backwards" compatible with the "standard" usage.
Actually I'm not sure if Perl 6 allows ($u *= 5)++; because the return value of *= is the rvalue 5 and *not* $u as an lvalue. Correct me if I'm wrong. Otherwise how would the expanded form ($u = $u * 5)++; behave when extented by yet another assignment ($y = $u = $u * 5)++; # $y++ or $u++ and recollapsed as ($y = $u *= 5)++; say $y; # 6?
Now letting aside other reasons why the proposal should not be accepted, if it where, it would not be disruptive of current behavior.
I think there is a much deeper running unresolved issue in Perl 6 as of now: the underspecified execution model and how it relates to the type and OO system! I personally would like to see something akin to adjoined operators in mathematics. As in matrix multiplication where A * B * x with A and B matrizes and x a vector. The idea is that you don't start from the vector but pre-multiply A and B. That is the associativity is (A * B) * x At that stage you could drop the application to x and store the resulting action in another variable C := (A * B) for later application. Writing the above with Perl6 sigils would come out as &A * &B * $x; and then &C = &A * &B; is a calculated code object just like $y = $a * $b; is a calculated value. This is what I would call first class operators! BTW, I see junctions beeing a prime example of the above. And handling them through a data (non & sigiled) variable would prevent their magic to come forth unintentional. As a nice side effect the importance of the & sigil would be increased. --
