Mailing List Archive

PSC #024 2021-06-11
PSC #024 2021-06-11
Present: Nick, Rik, Neil


Supported Platforms
We talked about supported platforms, and some thoughts I'd put together and iterated on with Nick. I'll post those, and we agreed we should try to get to something "good enough", which will be better than what we have now. I'll post something on the relevant thread.


`no strict` before `use vN`, and what that means for warnings in 5.36 bundle
We had a loong discussion about `no strict` before `use vN`, and what this should mean for `no warnings`. This was prompted by my response on the thread about this[1], which Rik had replied to[2]. We have pages of notes. I argued that we should focus on least surprise for the bulk of Perl programmers – not complete beginners, but nor the handful of people who understand everything in the referenced threads. Rik quoted Larry at me[3]. I think we converged. Rik is going to write up a proposed mental model for this and email it to the list.


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.


try/fix and 5.34.1
We had a brief chat about try/fix and #18855. We'll ask Paul to prioritise fixing this for a 5.34.1 release. The fact that this wasn't caught before 5.34.0 suggests it didn't get any serious testing, so we talked about the next to ensure better testing prior to 5.34.1, so we don't get caught out again. We ask people who've used CPAN try/catch modules to exercise this, once Paul has fixed #18855.


When does `isa` stop being experimental?
We talked about "isa", which is currently experimental[5]. I asked what the criteria are for dropping the experimental from this? Perlpolicy says 2 stable releases and 1 release cycle with no design-changing bugs[6]. We think "isa" looks good, but has it been used, and seriously abused with all sorts of weird edge cases? Probably not. Nick will put together a list of ways to abuse interfaces in Perl, which we're hoping might end up somewhere in pod/, and which we’ll use to exercise isa a bit more.


Bug queues for dual-life modules
Data::Dumper is a dual-life module (released with Perl, but also gets independent releases on CPAN), upstream blead (changes should be done in blead, and then a release done to CPAN). Nick recently fixed some bugs that had been languishing because Data-Dumper has its own RT bug queue. Jim submitted a PR to change the CPAN release to direct people to Perl's github issues. Neil and Nick had different thoughts on this, so we discussed it.

In the end we agreed that the general policy for dual-life modules should be: perl's git issues queue for upstream blead, and their own issues tracker for upstream CPAN. There are some upstream blead dists that have their own repo – we'd like to move these repos, and their committers, into the perl organisation. This seems like the right place for upstream blead dists, and also means we'll be able to move tickets between repo's. Neil will put a +1 on the PR and Rik will approach the upstream blead repo owners.


The RFC process and formatting quadmath floating point numbers
In the context of the new RFC process, sisyphus said he'd like to see improvements in formatting of floating point values[7]. He wasn't sure whether he should submit an RFC, given he won't be in a position to implement it; and there are potentially licensing issues. Nick really got into his stride discussing quadmath and the like, but I can't do it justice. But the end result was: yes, please kick off the idea on p5p (in a separate thread), and we'd like to see this become an RFC. There's an existing C implementation which may have licensing issues, but we'll cross that bridge if we get to it.

We discussed a couple more points related to RFCs. Nick will send at least one email as a result.


The -Dusedefaultstrict Configure option
Jim has pointed out[8] that if you configure Perl with -Dusedefaultstrict, then it won't currently pass tests, due to some dual-life modules that are upstream CPAN. He wondered if we should remove the Configure option. We think a better approach is to first get those distributions all strict-clean, and then we can separately decide whether we think this Configure option should stay. I'll follow up on this, starting with Text-Tabs+Wrap.


Neil, Rik, Nick


[1] https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260328.html
[2] https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260329.html
[3] care to guess which one?
[4] https://github.com/Perl/perl5/pull/18848
[5] https://github.com/Perl/perl5/issues/18754
[6] https://perldoc.perl.org/perlpolicy#experimental
[7] https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260361.html
[8] https://github.com/Perl/perl5/issues/18872
Re: PSC #024 2021-06-11 [ In reply to ]
2021-6-13 18:02 Neil Bowers <neilb@neilb.org> wrote:

>
> *When does `isa` stop being experimental?*
> We talked about "isa", which is currently experimental[5]. I asked what
> the criteria are for dropping the experimental from this? Perlpolicy says 2
> stable releases and 1 release cycle with no design-changing bugs[6]. We
> think "isa" looks good, but has it been used, and seriously abused with all
> sorts of weird edge cases? Probably not. Nick will put together a list of
> ways to abuse interfaces in Perl, which we're hoping might end up somewhere
> in pod/, and which we’ll use to exercise isa a bit more.
>
>
I would like application users to try the isa operator to make it more
reliable. That's because CPAN can't check for isa bugs.

I would like to send a message to Perl users who are interested in the new
grammar and receive any problem reports about isa operator.
Re: PSC #024 2021-06-11 [ In reply to ]
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.

The () around the ternary sets OPf_PARENS on that op tree, but at that
point the op modified is a null op, with cond_expr as the child, and
the flag is set on that null op.

When newASSIGNOP() checks for list assignment it sees the null op,
skips it and starts checking from the child op, but this ends up not
being an issue, since...

Ternary ops have their own check before the parens check that
recursively performs the same checks on the true and false
expressions, so code like:

$x ? ($y) : (undef) = ...;

actually becomes the list assignment we might have expected from:

($x ? $y : undef) = ...;

It would be close to trivial to modify the behaviour to look for
parens in addition to the checks of the child ops, but that would
change the context of the right side of the assignment:

($x ? $y : undef) = foo(); # foo() currently called in scalar context

which would be a silent change in behaviour.

We could hide it behind a feature flag, but it's subtle enough I could
see it causing problems if that flag was later included in a feature
bundle.

Tony
Re: PSC #024 2021-06-11 [ In reply to ]
??????? Original Message ???????
On Sunday, June 13th, 2021 at 7:50 PM, Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> 2021-6-13 18:02 Neil Bowers <neilb@neilb.org> wrote:
>
>> When does `isa` stop being experimental?
>> We talked about "isa", which is currently experimental[5]. I asked what the criteria are for dropping the experimental from this? Perlpolicy says 2 stable releases and 1 release cycle with no design-changing bugs[6]. We think "isa" looks good, but has it been used, and seriously abused with all sorts of weird edge cases? Probably not. Nick will put together a list of ways to abuse interfaces in Perl, which we're hoping might end up somewhere in pod/, and which we’ll use to exercise isa a bit more.
>
> I would like application users to try the isa operator to make it more reliable. That's because CPAN can't check for isa bugs.

Can you explain to me why I should want to use it?

E.g., what's the advantage of "isa" over "ref", other than the it being infix? Even with Sub::Infix, I can do something like this:

use strict;
use warnings;
use Sub::Infix;
BEGIN {
*isa = infix { ref $_[0] eq $_[1] }
}
my $foo = bless {}, 'Foo';
if ($foo |isa| 'Foo') {
print qq{isa Foo ok\n};
}
else {
print qq{isa Foo not ok\n};
}
$foo = bless {}, 'Bar';
if ($foo |isa| 'Foo') {
print qq{isa Foo ok\n};
}
else {
print qq{isa Foo not ok\n};
}

So there seems to be 2 issues this is "solving":

a. a "deep" "ref" check (all the way up and down @ISA?)
b. dealing with the fact that what's being checked is not a reference and therefore has no access to UNIVERSAL::isa?

I just happened to find this when doing some "fact checking"; does this infix "isa" address the shortcomings of UNIVERSAL::isa?

https://stackoverflow.com/questions/204316/why-shouldnt-i-use-universalisa#204368

I also found the original GH issue, https://github.com/Perl/perl5/issues/17200 and I can't seem to find the answer to my questions.

Is there a good perldoc I can read about it so I know what to generally expect and what its proper uses cases are? I can't seem to find that. I did look.

Cheers,
Brett

> I would like to send a message to Perl users who are interested in the new grammar and receive any problem reports about isa operator.
Re: PSC #024 2021-06-11 [ In reply to ]
On Mon, Jun 14, 2021 at 12:09 AM mah.kitteh via perl5-porters <
perl5-porters@perl.org> wrote:

> b. dealing with the fact that what's being checked is not a reference and
> therefore has no access to UNIVERSAL::isa?
>

Not a blessed reference, specifically. It does also work on non-references,
since those are class names.

I just happened to find this when doing some "fact checking"; does this
> infix "isa" address the shortcomings of UNIVERSAL::isa?
>

Yes. It calls isa on the blessed reference, but doesn't throw an exception
when called on an unblessed reference or undef, thus replacing the common
(but not well known) idiom to do this correctly: `defined(blessed $thing)
&& $thing->isa($class)`

-Dan
Re: PSC #024 2021-06-11 [ In reply to ]
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!

So, Tony's email covered quite a bit of what I said I'd summarize, but I'll try to hit the points we had talked about.

$x = foo(); # scalar context
($x) = foo(); # list context
$x, $y = foo(); # scalar context, but clearly a bug; = is tighter than ,
($x, $y) = foo(); # list context

$x ? $t : $f = foo(); # scalar context

($x ? $t : $f, $z) = foo(); # list context; (remember that ?: bind tighter than ,)
($x ? $t : $f) = foo(); # scalar context
($x ? $s : @a) = foo(); # ambiguous! a warning is issued

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.

The reality of the situation, as Tony pointed out in his email, and as Matthew Horsfall pointed out to me in a chat, is that merely having "an expression in parens" on the left hand side is not sufficient to create list context. As Tony showed, you need to write something like:
$x ? ($t) : ($f) = foo();

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!

Tony suggests making ($x ? $y : $z) become a list assignment target, but this strikes me as pretty risky, for two reasons: First off, it's going to change the calling context of some yet-uncounted number of assignments. Secondly, clearly a few people immediately said, "No, assigning to a ternary in parens does not create list context", so they already understand. I don't get to declare my expectations correct just because somebody put a sticker next to my name.

I'm not sure I really have a great suggestion, here, except for this one: We should make sure that there is a clear explanation of how that context decision is made, and then somebody should point me at it so I can read it. ????

--
rjbs
Re: PSC #024 2021-06-11 [ In reply to ]
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