develooper Front page | perl.perl5.porters | Postings from June 2021

Re: PSC #024 2021-06-11

Thread Previous | Thread Next
From:
Tony Cook
Date:
June 16, 2021 00:24
Subject:
Re: PSC #024 2021-06-11
Message ID:
20210616002411.GK3719@venus.tony.develop-help.com
On Tue, Jun 15, 2021 at 02:21:24PM -0400, Ricardo Signes wrote:
> On Sun, Jun 13, 2021, at 9:43 PM, Tony Cook wrote:
> > On Sun, Jun 13, 2021 at 10:01:33AM +0100, Neil Bowers wrote:
> > > Assignment to undef, and a quirk
> > 
> > > Tony C submitted a PR on 2021-06-02 which changes the behaviour on
> >   assigning to undef within a ternary[4]. We discussed whether
> >   assigning should be legal in any context. But we then ended up
> >   looking at what was really going on with ($x ? $y : undef). Rik
> >   started dumping out op trees for different examples, and bouncing
> >   back & forth with Nick on what was going on. Oh how naive I was,
> >   thinking the previous topic went on for a long time. Rik is going to
> >   email a summary of this, with a suggestion for what might change.
> > 
> > It's a bit strange.
> 
> Yes!

I was thinking of the way the implementation worked, in that
conditional expressions manage to ignore the () in two different ways
(that null op I mentioned is explicitly added when the conditional is
created.)

But the behaviour is unexpected too.

> It is easy to read this and think the following thoughts:
>  * to turn a scalar assignment into a list
>  * except if that expression is a ternary alone inside the parens, where the compiler optimizes us into scalar assignment
>  * if the compiler can decide to shift between AASSIGN and SASSIGN as an optimization, they must have equivalent semantics for assignment to the literal undef
> This is sort of where we ended up, feeling confused, on our last PSC call.

I don't think it's intended as any sort of code optimization.

It may be intended as a readability optimization, if you're unsure on
the precendence of ?: and =, or expect someone else reading the code
to be unsure, then:

  ($a ? $b : $c) = ...;

may be more readable than:

  $a ? $b : $c = ...; # did he mean C<< $a ? $b : ($c = ...); >> ?

> This isn't the same thing as "the compiler optimized".  It's a
  question, I think, of how the language is meant to work.  The
  problem is that it leave me thinking, "I don't really know what the
  clear rule is for 'is this assignment going to be in list context'".
  This is not a situation I like to be in!

The code that does the check (S_assignment_type() in op.c) is
reasonably readable for code that deals with ops.

Tony

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