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 15, 2010 06:33
Subject:
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
AANLkTilcY0URrTOD3X-YxO7EAuEL68FH0Cgz4KE7Ju4U@mail.gmail.com
On 15 July 2010 13:24, Dave Mitchell <davem@iabyn.com> wrote:
> On Thu, Jul 15, 2010 at 10:31:51AM +0200, demerphq wrote:
>> On 15 July 2010 01:12, Dave Mitchell <davem@iabyn.com> 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 <hv@crypt.org>
>> > AuthorDate: Sat May 26 18:05:12 2001 +0100
>> > Commit: Jarkko Hietaniemi <jhi@iki.fi>
>> > CommitDate: Sat May 26 22:31:46 2001 +0000
>> >
>> > Re: 5.6.*, bleadperl: bugs in pp_concat
>> > Message-Id: <200105261605.RAA12295@crypt.compulink.co.uk>
>>
>> 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?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next