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

Re: chained comparisons

Thread Previous | Thread Next
Tomasz Konojacki
April 9, 2020 17:16
Re: chained comparisons
Message ID:
On Wed, 8 Apr 2020 06:33:08 +0100
Zefram via perl5-porters <> 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. 

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About