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 14, 2010 00:39
Subject:
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
AANLkTin1k9L3UOCAdv7-b1PSqyH00Dm82-wy0fOaxfjJ@mail.gmail.com
On 14 July 2010 00:24, Eric Brine <ikegami@adaelis.com> wrote:
> On Tue, Jul 13, 2010 at 1:55 PM, Ben Morrow <ben@morrow.me.uk> wrote:
>
>> Quite. And
>>
>>    print $i++, $i++;
>>
>> has DWIM forever (probably since perl 1).
>
>
> Bad example. The operand evaluation order for the comma operator is not
> undefined. It's documented that the arguments are evaluated from left to
> right (allowing the comma can be used a "light" semicolon). A better example
> would be
>
> print $i-- + $i++;
>
> The operand evaluation order of addition is not documented, so it could
> return 5 or 7 for $i=3. But it always returns 5.
>

I concur. Certain operators make explicit guarantees about order of
evaluation, and as such we cannot change them. Most operators do not,
for instance non of the mathematical or comparison operators, nor
concatenation. Whomever decided that

  $a . $a

is specified when $a is tied and returns a different value each fetch
had forgotten this fact.

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