Mailing List Archive

1 2  View All
Re: disabling smartmatch and when()? [ In reply to ]
Hi there,

On Fri, 24 Jun 2022, Ricardo Signes wrote:
> On Tue, Jun 21, 2022, at 04:45, Paul "LeoNerd" Evans wrote:
>> I think there's two things we need to do:
>>
>> 1) Make ~~ and given/when much louder about their "you shouldn't use
>> this for new code" status;
>
> Agreed. Let's do that immediately?
>
>> 2) Create a better replacement
>
> I'm all for having a better replacement, but I continue to strongly oppose the idea that we *need* one to remove the old thing.
>
> I write a lot of Perl, and have since before smartmatch was introduced. I never used smartmatch for much. I have banned it from my projects. I have seen it largely unused. Nothing it does can't be done some other way already, although sometime more verbosely. We don't need a replacement, because *we have gotten along fine without using it for 20 years.*
>
> A replacement would be nice, if it's good, but it doesn't need to exist before we take the old thing out.

My sentiments exactly.

I briefly flirted with 'given'. In 2017 I abandoned it, and swore that it would be forever.

Even if there's a new one, I doubt I'd take the risk.

--

73,
Ged.
Re: disabling smartmatch and when()? [ In reply to ]
On Fri, 24 Jun 2022 10:07:25 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> On Tue, Jun 21, 2022, at 04:45, Paul "LeoNerd" Evans wrote:
> > I think there's two things we need to do:
> >
> > 1) Make ~~ and given/when much louder about their "you shouldn't use
> > this for new code" status;
>
> Agreed. Let's do that immediately?

Righty. I'll see what I can hack up.

> > 2) Create a better replacement
>
> I'm all for having a better replacement, but I continue to strongly
> oppose the idea that we *need* one to remove the old thing.
...
> A replacement would be nice, if it's good, but it doesn't need to
> exist before we take the old thing out.

Agree - these are two separate things. We can do them independently.

> I write a lot of Perl, and have since before smartmatch was
> introduced. I never used smartmatch for much. I have banned it from
> my projects. I have seen it largely unused. Nothing it does can't
> be done some other way already, although sometime more verbosely. We
> don't need a replacement, because *we have gotten along fine without
> using it for 20 years.*

Yah I'm inclined to agree. But also we're honestly most of the way
there in terms of designing nicer replacements.

Most of the weird funky cases of the ~~ operator (e.g. the array
distributative nature of $str ~~ @arr) can be handled with things like
List::Util::all - of which I hope to have a nicer core syntax soon.
Plus once I finish working out how to do parametric syntax using
XS::Parse::Infix, I'll have the `in<eq>` and `in<==>` operators. For
now there's `$str elem @arr_of_strings` and `$num ? @arr_of_nums`
operators (yes the latter requires UTF-8, because I couldn't find a
free sequence of ASCII symbols that makes sense) provided by
Syntax::Operator::Elem (which I really should get onto CPAN soon).

Most of the simpler uses of given/when are just as tidy with my
match/case syntax, provided by Syntax::Keyword::Match. It's an evolving
design that I hope to drag into core sometime, much like the design
process that lead to try/catch in core.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: disabling smartmatch and when()? [ In reply to ]
On Fri, 24 Jun 2022 16:11:58 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> On Fri, 24 Jun 2022 10:07:25 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
> > On Tue, Jun 21, 2022, at 04:45, Paul "LeoNerd" Evans wrote:
> > > I think there's two things we need to do:
> > >
> > > 1) Make ~~ and given/when much louder about their "you shouldn't
> > > use this for new code" status;
> >
> > Agreed. Let's do that immediately?
>
> Righty. I'll see what I can hack up.

Hmm. Well, first off: we don't have a "discouraged" warning category.

One thing we do have is "deprecated", which I think current policy
requires us to make a formal statement in pod/perldeprecation.pod and
give a timeline for eventual removal. Do we want to commit to that?

Alternatively, I could add a new "discouraged" category. Though I think
I recall trying that sometime before and we eventually decided it
should just be deprecated anyway.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: disabling smartmatch and when()? [ In reply to ]
On Fri, Jun 24, 2022, at 11:59, Paul "LeoNerd" Evans wrote:
> One thing we do have is "deprecated", which I think current policy
> requires us to make a formal statement in pod/perldeprecation.pod and
> give a timeline for eventual removal. Do we want to commit to that?
>
> Alternatively, I could add a new "discouraged" category. Though I think
> I recall trying that sometime before and we eventually decided it
> should just be deprecated anyway.

Discouraged was created, more or less, for "we don't think this is a good idea but don't plan to get rid of it." I don't think we should warn on those. Put it in the linter.

But I think we really want to remove smartmatch, so it should be deprecated. Since replacement and removal are disconnected, I think we can set a date if we like. I'd say 5.42 probably, but am open to negotiations. ????

--
rjbs
Re: disabling smartmatch and when()? [ In reply to ]
On Fri, 24 Jun 2022 at 22:07, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> I'm all for having a better replacement, but I continue to strongly oppose
> the idea that we *need* one to remove the old thing.
>

Do we _need_ to remove smartmatch before that happens? What development is
currently blocked by having it in place? We don't like the way it works,
sure - but in that case why are other frequently-misused constructs such as
`each %hash` still in core?


> I write a lot of Perl, and have since before smartmatch was introduced. I
> never used smartmatch for much. I have banned it from my projects. I have
> seen it largely unused. Nothing it does can't be done some other way
> already, although sometime more verbosely. We don't need a replacement,
> because *we have gotten along fine without using it for 20 years.*
>

A reminder of what was posted earlier in the discussion -
https://www.nntp.perl.org/group/perl.perl5.porters/2022/06/msg264093.html:

> The result of the above is that half of CPAN relies on smartmatch:
>
>
https://grep.cpanauthors.org/search?q=%7E%7E+OR+%22given+%28%22+OR+%22given%28%22
>
> And that is just CPAN, there's certainly a lot of it in darkpan code too.

which makes "largely unused" an over-generous interpretation of the current
situation, at best!

If you need more statistics: over 30% of the PSC have code _right now_ on
CPAN relying on smartmatch. If we can't trust the guiding lights of the
Perl core development team to be using the "right parts" of Perl, what hope
for casual developers?

Put another way, I could write your paragraph replacing "smartmatch" with
something like "Moose", and I'd hope that anyone could instantly recognise
that as a flawed line of thinking: people _are_ actively using these
things, we can see that on CPAN, even if specific individual developers can
safely claim not to be using the feature or affected by its removal.


> A replacement would be nice, if it's good, but it doesn't need to exist
> before we take the old thing out.
>

I would suggest that it does.

We went from "Perl does not have `switch`/`case`, just use `if`", to "Perl
has something better than `switch`/`case`, everyone use that instead", and
now it's back to "just use if, we have no realistic plans for improving
this". Taking this away is likely to trigger a significant amount of extra
work on code that's mostly in maintenance mode or worse, and "we took away
a feature and have no replacement" is something I would read as a red flag
and a sign of accelerating language demise. Perception and trust is a
significant part of this: I see this contributing to a sense of "even the
'new' features aren't something we can trust to be around in future".

A clear deprecation path _and_ non-experimental replacement would be needed
before removing smartmatch: what can the community outside P5P do to help
make this happen?
Re: disabling smartmatch and when()? [ In reply to ]
On Sat, Jun 25, 2022, at 08:09, Tom Molesworth wrote:
> On Fri, 24 Jun 2022 at 22:07, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>> __
>> I'm all for having a better replacement, but I continue to strongly oppose the idea that we *need* one to remove the old thing.
>
> Do we _need_ to remove smartmatch before that happens?

No. We can do them in either order.

> What development is currently blocked by having it in place? We don't like the way it works, sure - but in that case why are other frequently-misused constructs such as `each %hash` still in core?

"each" has been in Perl since at least v3. (I didn't look further back, I just grabbed my pink camel.) The documentation mentions it's a bit fragile, but that's about it. (Oral tradition, of course, is that it's A Big Mess.)

On the other hand, for nine years, ~~ has issued a warning described as:
This is currently an experimental feature, and its details are subject to change in future releases of Perl. Particularly, its current behavior is noticed for being unnecessarily complex and unintuitive, and is very likely to be overhauled.

So, why is smartmatch more available for chopping than each? Because we've been saying so for nearly a decade.

Is it worth whatever kerfuffle will be caused by removing it? I don't know yet. Or, what might need to be done to further make it palatable, if possible? Improve the message emitted, etc.

> > The result of the above is that half of CPAN relies on smartmatch:
> >
> > https://grep.cpanauthors.org/search?q=%7E%7E+OR+%22given+%28%22+OR+%22given%28%22

Could somebody elaborate on how we get from that link to "half of CPAN"?

>> A replacement would be nice, if it's good, but it doesn't need to exist before we take the old thing out.
>
> I would suggest that it does.
>
> We went from "Perl does not have `switch`/`case`, just use `if`", to "Perl has something better than `switch`/`case`, everyone use that instead", and now it's back to "just use if, we have no realistic plans for improving this".

The second state existed only very briefly in the mouths of p5p.
* Twenty years: Perl doesn't have a case statement.
* One year: Perl has a useful case statement alternative!
* Four years, *tops*: Okay, that was bad, but we made it better.
* Nine years: Okay, it's a mess, we maybe going to radically change or ditch it so don't rely on it.
--
rjbs

1 2  View All