Front page | perl.perl5.porters |
Postings from November 2017
On 29 October 2017 at 14:49, Dave Mitchell <davem@iabyn.com> wrote:
> On Sun, Oct 29, 2017 at 11:23:13AM +0100, demerphq wrote:
>> I've tried very hard to be bug-for-bug compatible with existing behaviour.
>> See for example this code comment in pp_multiconcat()!
>>
>> /* special-case $tied .= $tied.
>> *
>> * For something like
>> * sub FETCH { $i++ }
>> * then
>> * $tied .= $tied . $tied . $tied;
>> * will STORE "4123"
>> * while
>> * $tied .= $tied
>> * will STORE "12"
>> *
>> * i.e. for a single mutator concat, the LHS is
>> * retrieved first; in all other cases it is
>> * retrieved last. Whether this is sane behaviour
>> * is open to debate; but for now, multiconcat (as
>> * it is an optimisation) tries to reproduce
>> * existing behaviour.
>>
>> But no doubt there will be a whole bunch of things I didn't anticipate,
>> and I look forward to the inevitable slew of BBC tickets.
>>
>>
>> But wouldn't we consider this a bug we should fix?
>>
>> $x.= EXPR;
>>
>> Should be the same as
>>
>> $x = $x . EXPR;
>
> From perlop:
>
> Assignment operators work as in C. That is,
>
> $x += 2;
>
> is equivalent to
>
> $x = $x + 2;
>
> although without duplicating any side effects that dereferencing the
> lvalue might trigger, such as from C<tie()>. Other assignment
> operators work similarly.
>
> So they're not quite the same.
That comment goes back to the
a0d0e21ea6ea90a22318550944fe6cb09ae10cda, the 5.000 patch.
Personally I read that as documenting what we do, not that it is correct.
It seems to me that if someone noticed this behavior and filed a bug
about it we would not consider a feature but a bug.
But I totally get that it is not an issue that should be addressed as
part of this optimization.
> There are also two conceptually different
> activities: retrieving the lvalue or rvalue, and evaluating it. For
> example a tied array could return overloaded objects. So in
>
> $tied[0] = $tied[0] . $tied[1];
> $tied[0] .= $tied[1];
> $tied[0] .= $tied[1] . $tied[2];
>
> trying to determine the exact number and order of FETCH(), '.'-overload
> and '.='-overload calls is somewhat non-obvious.
Isn't that non-obviousness a byproduct of the "12" vs "4123" discrepancy?
It seems to me that if this behavior was well defined then both this
question and the discrepancy would go away.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next