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

Re: chained comparisons

Thread Previous | Thread Next
From:
demerphq
Date:
April 28, 2020 07:34
Subject:
Re: chained comparisons
Message ID:
CANgJU+VBmr9DUvdjDzced5A0=KrELhFzk-sHm_NayE6Q6FC_3w@mail.gmail.com
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/"

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