develooper Front page | perl.perl5.porters | Postings from April 2020

Re: chained comparisons

Thread Previous | Thread Next
From:
David Nicol
Date:
April 28, 2020 15:03
Subject:
Re: chained comparisons
Message ID:
CAFwScO8RMkiF0R60M2TC7ePbsV-eXk3=z0+aWFhD0s_Ov-TZ3Q@mail.gmail.com
does turning the tied thing into an expression by applying a no-op to it in
perl code prevent the second fetch?

lower <= 0+$tied_thing < upper

lower le "$tied_thing" lt upper

On Tue, Apr 28, 2020 at 2:34 AM demerphq <demerphq@gmail.com> wrote:

> On Thu, 9 Apr 2020 at 19:16, Tomasz Konojacki <me@xenu.pl> wrote:
>
>> On Wed, 8 Apr 2020 06:33:08 +0100
>> Zefram via perl5-porters <perl5-porters@perl.org> wrote:
>>
>> > Tony Cook wrote:
>> > >+    if (UNLIKELY(SvGMAGICAL(right))) {
>> > >+        right = sv_mortalcopy(right);
>> > ...
>> > >prevents the duplicate get magic, though it has the cost of
>> > >duplicating the value if it is magic,
>> >
>> > It causes the semantic problem that the scalar passed to the comparison
>> op
>> > (including to any overloaded comparison sub) is not the scalar specified
>> > by the operand expression.  Most comparison code doesn't care, of
>> course,
>> > but in general it's allowed to care.  Also note that the preexisting
>> > semantics don't have any principle of avoiding repeated get magic,
>> > even when comparison code isn't doing anything weird:
>> >
>> > $ cat t0
>> > use feature "say";
>> > package Aaa {
>> >     sub TIESCALAR { bless([]) }
>> >     sub FETCH { say "fetching"; 3 }
>> > }
>> > package Bbb {
>> >     use overload
>> >         "<=>" => sub { say "overloading"; (5 <=> $_[1]) * ($_[2] ? -1 :
>> 1) },
>> >         fallback => 1;
>> > }
>> > tie($a, "Aaa");
>> > $b = bless([], "Bbb");
>> > say "start";
>> > say $a < $b ? "yes" : "no";
>> > $ perl5.28.0 t0
>> > start
>> > fetching
>> > overloading
>> > fetching
>> > yes
>>
>> I don't understand what this snippet is supposed to show. There are two
>> FETCHes because $a is being evaluated twice (once as $a and once as
>> $_[1]).
>> There are two **explicitly** separate uses of the variable in the code.
>> This
>> is absolutely not the case with the chained comparison.
>>
>>
>> > So it is already the case that the only viable mental model for get
>> magic
>> > on comparison is that processing get magic, however many times it
>> happens,
>> > is part of the semantics of the comparison per se.  The chained
>> comparison
>> > system, in the form in which I implemented it, is coherent with this
>> > model, and any change in the behaviour would require a more complex
>> model
>> > to explain.  The patchwork semantics implied by the conditional copying
>> > that you propose would have to be matched by a patchwork explanation,
>> > even if we were to ignore the lvalue issue.
>> >
>> > >Another solution might be to add op flags to each of the comparison
>> > >ops to skip get magic on their left arguments, and set that when
>> > >building the chain.  This would be a more significant change though.
>> >
>> > Yes, and it wouldn't play nicely with anything that customises
>> comparison
>> > ops.  Such a less-compatible change isn't out of the question, but
>> > seems unwarranted to me, and in any case would have to wait for the next
>> > dev cycle.
>> >
>> > -zefram
>>
>> Multiple people both on the list and on #p5p were claiming that this
>> feature's semantics are "obvious" and thus it doesn't need an experimental
>> warning. I think we should rethink that.
>>
>
> It behaves exactly like the expression it replaces. I see no problem here.
> I think the implication that many will be confused is unfounded. The
> behavior is documented. That should be sufficient.
>
> Yves
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
>


-- 
"Amageddon, enthen armagedfunki."

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About