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

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

Thread Previous | Thread Next
July 15, 2010 06:33
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
On 15 July 2010 13:24, Dave Mitchell <> wrote:
> On Thu, Jul 15, 2010 at 10:31:51AM +0200, demerphq wrote:
>> 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!
>> >
>> > 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 wasn't making a point, I was just providing information.
>> 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?
> Just to make it clear, I didn't post that patch to prove a point one way
> of another, I just dug it up as a point of info so that people could, if
> interested, examine it, look at at the reasoning behind it (e.g. the p5p
> discussion if any), and draw whatever conclusions they want. For the
> record, I haven't read the original 2001 p5p thread, and haven't drawn any
> conclusions.

My apologies for making the incorrect inference. Clarification understood.

> However, for my opinions for the topic in hand...
> as regards tiedness, there are actually two orthogonal issues of
> correctness. The first is which order in which the two $a's in $a.$a are
> evaluated; the second is how many times $a is evaluated. It is quite
> possible for the order not to be defined, but still for the fact that $a
> is evaluated twice to be defined.

Yes, agreed. i dont have any issue with calling tie twice, and would
expect that it happens. I just wouldn't expect it to happen in a
particular order, nor that that patch makes the expression /defined/.

> For example, someone might be using tie
> to instrument the number of accesses to a variable. Having said that, tied
> hash elements only have mg_get called once on them until reset by a
> mg_set, and I recently extended that mechanism to tied arrays too.

What does this mean exactly.

> On the other hand, it may not be documented or specified, but I think most
> people would expect that in the following, f() is called before g():
>    $f() . $g()

Hmm. I don't know that I would. If we want this to be the case then
IMO we should document it.

> Finally, my feeling is that any 'no magic;' scopes aren't really viable in
> terms of providing enough guarantees of side-effects for aggressive
> optimisation while still providing perly behaviour.

Ok, thanks. What is the main problem as you see it?


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

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