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

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

Thread Previous | Thread Next
Reini Urban
July 15, 2010 04:29
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
2010/7/15 demerphq <>:
> On 15 July 2010 01:12, Dave Mitchell <> wrote:
>> On Wed, Jul 14, 2010 at 09:39:35AM +0200, demerphq wrote:
>>> Whomever decided that
>>>   $a . $a
>>> is specified when $a is tied and returns a different value each fetch
>>> had forgotten this fact.
>> You'll have to argue that with Hugo then!

I'm also with Yves here.
Hugo destroyed language semantics with 5.6.2, if I read the pp_hot.c
patch right.

$a . $a must evaluate $a twice, and not only once,
even if it saves coding lines for the construct
my $b = $a; $b . $b
which should be done if you want to evaluate $a only once.
We don't want to surprise users in favor of having to write less code.

In our case we need:
1. document this special evaluation rule for the pp_concat op
("if both sides of . refer to the same tied variable, the tied access
is only done once, contrary to the obvious")
or preferred:
2. revert the pp_concat patch from Hugo,
  so that $a.$a evaluates mg_get twice again for $a

This is would you expect from reading $a . $a.
If you want to evaluate it once, do it once. Typical semantics would be
{ my $b = $a; $b . $b }

But we certainly need a testcase for this mg_get sideeffect.

>> commit 8d6d96c1bf85fd984f18f84ea834be52b168c812
>> Author:     Hugo van der Sanden <>
>> AuthorDate: Sat May 26 18:05:12 2001 +0100
>> Commit:     Jarkko Hietaniemi <>
>> CommitDate: Sat May 26 22:31:46 2001 +0000
>>    Re: 5.6.*, bleadperl: bugs in pp_concat
>>    Message-Id: <>
> I'm not sure what your point is? Simply because Hugo wrote/pushed a
> patch that somehow proves something? I don't think so. Just because a
> commiter didn't think through the full ramifications of a patch, or
> even knew of the ramifications but still went through with it on the
> grounds of providing "least worst" behaviour doesn't make that patch
> law over long existing documentation.
> The documentation for ++ is pretty clear.
> If the concatenation of a tied variable that mutates is well
> specified, then it would mean that one can take a construct documented
> to have unspecified behaviour wrap it up in a tie to resolve the
> unspecifiedness, which seems to me to be simply absurd.
> Thus the onus is not on me to show why this is unspecified, as the
> docs say it is, the onus instead is on those who disagree with the
> documentation to find a way to get out of this logical absurdity.
> I have to say that I'm struggling to see why what you just posted
> doesn't essentially boil down to a position that the docs are
> meaningless and that whatever is committed is right. If so then you
> might as well stop fixing those "bugs" as they aren't really "bugs"
> then are they? I'm pretty sure you don't think this, so why do you
> think that this patch is different?
Reini Urban 

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About