Front page | perl.perl5.porters |
Postings from July 2010
2010/7/15 demerphq <demerphq@gmail.com>:
> 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!
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 <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 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
http://phpwiki.org/ http://murbreak.at/
Thread Previous
|
Thread Next