Mailing List Archive

* Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-07-16 16:02:23 +0100]:

> Minutes from my first time taking them, for the PSC meeting:
>
>
> Neil and Paul present. Rik couldn't attend due to prior work commitment.
>
>
> We discussed the quirks doc - nothing to do yet. Neil intends to finish
> collecting thoughts over the weekend and publish something.
>
> Discussed PR#17771 (Tux's DynaLoader 64bit directories monkeypatch). We
> agree that the situation is not something Perl should be attempting to
> fix ("configure on one machine, move to a different one with different
> dirs"), so we agree to close it.
>
> Leon's PR#18666 ("use VERSION should imply use warnings"). It needs
> poking to fix/finish it - either get leont to do that or find someone
> else to. Action: Paul commented on PR, emailed p5p@.
>
> G_LIST PRs (PR#18851, PR#18852) - Action: Paul should work out what to
> do to further these - likely poke khw and/or atoomic.
>
> Discussed NV vs PV and what it means (with respect to PR#18958)
> Discussed knock-on effects on CPAN modules - code might break? but
> that's always going to happen. Maybe people's unit tests might break -
> they can version-guard. Two questions: Is this the right change? And
> how to handle fallout? After we decide to proceed, it should be easy to
> review the PR to check it's the right way to do it. Action: Paul will
> start a thread of "is this a good idea?" on p5p@
>
> On `unbless` - we haven't needed it in 20 years. The existing "TO JSON"
> arguments don't seem valid. Corinna will obviate it anyway. Not going
> to core - there's existing CPAN modules for it - Acme::Damn and
> similar. It's not even clear that it's worth adding to Scalar::Util.
>

Thank you for considering it. I'd recommend not defending a decision
like this, just please say "no" or "not at this time". And point to the
CPAN options. Why? It's not helpful and it actually weakens your own
ability to take positions on things. E.g.,

1. "haven't needed it in 20 years"

Wow, this can be used for literally anything. Idk, like "trim", or
"Perl OOP", etc. So it's wholly unproductive and you're begging
for this to get thrown in your face. I doubt that's what you want.

2. "Corinna will obviate it anyway"

Again, not necessary. Not germane to the request, and personally strikes
me as biased and inflamatory. Not needed nor productive.

3. Scalar::Util

Regarding adding it to Scalar::Util, you asked for someone to create a
"issue" on RT. I did, so it's clearly there whenever there is someone
who is willing to do so. Personally, I hope it shows up in S::U at some
point. If you need some clarity on its utility, this SO has been viewed
17,000 times (you see this is tied to serialization, like it or not - and
I don't think that's my primary use case; but it is a well understood one):

https://stackoverflow.com/questions/2329385/how-can-i-unbless-an-object-in-perl

So I can see it coming up again. I was quite shocked at the response
about it - on the net, a positive one I thought. Anyway.

4. Data::Structure::Util

FWIW, https://metacpan.org/pod/Data::Structure::Util no longer comes up
when I search for "unbless" in MCPAN which is strange. It has a river
position of 2, whereas Acme::Damn is a 1. Not sure what happened but
maybe MCPAN's search is broken. But this is the module I actually pointed
to originally, not Acme::Damn (or the other one that's just a wrapper w/
fall back to deep copy).

Cheers
Brett

>
> On `weaken` - should it be core language? It's a fundamental language
> ability, it seems odd not to be a keyword. Perhaps we could add it. But
> if we do, it's the start of a slippery slope to pull in more things
> from Scalar::Util, and maybe List::Util. And this seems to lead
> naturally to the discussion of namespaces again and whether we want to
> bring in a hundred or so new functions.
>
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Sat, 17 Jul 2021 at 05:54, Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> * Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-07-16 16:02:23
> +0100]:
> > On `unbless` - we haven't needed it in 20 years. The existing "TO JSON"
> > arguments don't seem valid. Corinna will obviate it anyway. Not going
> > to core - there's existing CPAN modules for it - Acme::Damn and
> > similar. It's not even clear that it's worth adding to Scalar::Util.
> >
>
> Thank you for considering it. I'd recommend not defending a decision
> like this, just please say "no" or "not at this time". And point to the
> CPAN options. Why? It's not helpful and it actually weakens your own
> ability to take positions on things. E.g.,
>

The PSC minutes document the meeting's discussion and decisions - having
that background on file is useful if additional points come up in future.

* Tom Molesworth <tom@binary.com> [2021-07-17 06:56:19 +0800]:

> On Sat, 17 Jul 2021 at 05:54, Oodler 577 via perl5-porters <
> perl5-porters@perl.org> wrote:
>
> > * Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-07-16 16:02:23
> > +0100]:
> > > On `unbless` - we haven't needed it in 20 years. The existing "TO JSON"
> > > arguments don't seem valid. Corinna will obviate it anyway. Not going
> > > to core - there's existing CPAN modules for it - Acme::Damn and
> > > similar. It's not even clear that it's worth adding to Scalar::Util.
> > >
> >
> > Thank you for considering it. I'd recommend not defending a decision
> > like this, just please say "no" or "not at this time". And point to the
> > CPAN options. Why? It's not helpful and it actually weakens your own
> > ability to take positions on things. E.g.,
> >
>
> The PSC minutes document the meeting's discussion and decisions - having
> that background on file is useful if additional points come up in future.

That's fair :)

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

2021-7-17 6:54 Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote :

>
> 1. "haven't needed it in 20 years"
>
> Wow, this can be used for literally anything. Idk, like "trim", or
> "Perl OOP", etc. So it's wholly unproductive and you're begging
> for this to get thrown in your face. I doubt that's what you want.
>
>
>
I feel that the Perl core team can't add functions(This means normal
functions of name spaces of Perl Core modules, not as features) because of
the anxiety that a huge amount of functions will be added.

Before the individual discussion, we first need to discuss whether we want
to add functions to the namespace of Perl Core Modules.

In addition, it is necessary to discuss how much demand exists to be able
to add.

Many people, including myself, feel that there are missing functions in the
Perl core, but there is not yet a consensus.

* Yuki Kimoto <kimoto.yuki@gmail.com> [2021-07-19 08:19:05 +0900]:

> 2021-7-17 6:54 Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote :
>
> >
> > 1. "haven't needed it in 20 years"
> >
> > Wow, this can be used for literally anything. Idk, like "trim", or
> > "Perl OOP", etc. So it's wholly unproductive and you're begging
> > for this to get thrown in your face. I doubt that's what you want.
> >
> >
> >
> I feel that the Perl core team can't add functions(This means normal
> functions of name spaces of Perl Core modules, not as features) because of
> the anxiety that a huge amount of functions will be added.

It's more than that. I think it has to do with a lot of mutual distrust
and lack of confidence on many sides. And there are many sides. This has
been my primary conclusion over years of observing things here and the
recent months of my own personal engagement here. We'd do well to identify
this further, then fix it..somehow.

>
> Before the individual discussion, we first need to discuss whether we want
> to add functions to the namespace of Perl Core Modules.
>

There's likely an approach to quantitatively determine what things are
"missing" based on some basic definition of "completeness". Starting
there would likely be a good step to addressing this. Once the set of core
key words can be said to be "complete", even if not internally consistent,
then I think everyone would have a much better basis to determine what is
actually "missing".

For example, a large amount of energy was put into what "trim" returned and
if it affected it's argument. Why? Because of "chomp". The desire to keep
things consistent with "chomp", e.g., was not because "chomp" does it "right";
but because a "trim" that did something different was introducing a new and
inconsistent behavior in something that most likely would be replacing
chomp in many cases.

So getting a handle on these things and understanding the different variations
that exist is important. Using trim/chomp as another example, there probly
would have been little to no argument if a "tromp" was being introduced
that "worked like chomp but also delebed leading whitespace".

Instead, the opportunity was taken to make too many changes at once. And on
top of that, introduce a totally different calling convention that no
other keyword exhibitied.

Of course I can only speak for myself, but this is my feeling and why I
personally advocate a slow and conservative extension to the namespace - i.e.,
until we more fully understand how we can make things more consistent, or
at least stop making them more inconsistent.

>
> In addition, it is necessary to discuss how much demand exists to be able
> to add.
>
> Many people, including myself, feel that there are missing functions in the
> Perl core, but there is not yet a consensus.

Interesting thought. In the same vein as the "Perl Quirks" document
seems to have been a success (based on my observations of the
document, though I did not personally contribute); perhaps a similar
exercise for "Missing Perl Features" would good? Maybe set some
few ground rules, e.g., we know some people are going to put "OOP",
so maybe just assume that one.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

2021-7-19 12:57 Oodler 577 <oodler577@sdf-eu.org> wrote:

>
> exercise for "Missing Perl Features" would good?
>

I feel "Missing Perl Features" is a good idea.

I would like to know what other programming languages have strong
complaints that Perl does not have.

Maybe Prevent that People make suggestions repeatedly and PSC rejects them
repeatedly.