develooper Front page | perl.perl5.porters | Postings from July 2010

Re: [perl #76438] peephole optimiser could prune more dead code

Thread Previous | Thread Next
From:
demerphq
Date:
July 13, 2010 05:02
Subject:
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
AANLkTindpP2kFfWEDNIkBnMBOznBng89Y7HBoimAfYxz@mail.gmail.com
On 13 July 2010 13:43, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth demerphq@gmail.com (demerphq):
>> On 12 July 2010 20:30, Dave Mitchell <davem@iabyn.com> wrote:
>> > On Mon, Jul 12, 2010 at 06:06:15PM +0200, Reini Urban wrote:
>> >> gvsv is just checking magic and doing the sideeffect
>> >
>> > Huh? gvsv doesn't call magic.
>> >
>> > Also, just as a data point, note that pp_concat *explicitly* calls get
>> > magic twice on $a . $a:
>> >
>> >        if (left == right)
>> >            /* $r.$r: do magic twice: tied might return different 2nd time */
>> >            SvGETMAGIC(right);
>>
>> Id like to argue that this was misguided. I dont think we guarantee
>> any particular order in this case for the fetch calls and thus the
>> statement is /still/ undefined even with this change.
>
> Perl doesn't have undefined behaviour. No matter what weasel words
> copied from stdc made it into the ++ docs, Perl's actual evaluation
> order has always been straightforward and well-defined. Changing this
> may be worth it, for a sufficiently beneficial optimisation, but it is
> definitely a backwards-incompatible change.

Just so everyone can conveniently see:

From perldoc perlop:

       Auto-increment and Auto-decrement

       "++" and "--" work as in C.  That is, if placed before a
variable, they increment or decrement the variable by one before
returning the value, and if placed after, increment or decrement after
returning the value.

           $i = 0;  $j = 0;
           print $i++;  # prints 0
           print ++$j;  # prints 1

       Note that just as in C, Perl doesn’t define when the variable
is incremented or decremented. You just know it will be done sometime
before or after the value is returned. This also means that modifying
a variable twice in
       the same statement will lead to undefined behaviour.  Avoid
statements like:

           $i = $i ++;
           print ++ $i + $i ++;

       Perl will not guarantee what the result of the above statements is.

If we are going to say that these statements are well defined then we
should probably document exactly what the rules are, as well as
correcting the above docs.

Ill just say that in this case I would much prefer we dont change the
documentation, except to make this much more prominent in the Tie and
Overload documentation. There is more benefit for more people if we
can take advantage of the undefinedness than there is harm done to
people doing naughty things like this despite the documentation (they
are saved only by the lack of prominence of this documentation).

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About