A smaller-than-usual meeting because of the US Holiday; only Paul and Philippe today.

• We remembered we still need to write the announcement for deprecating smartmatch
• We need to resync with Neil about how "SSL in Core" investigations are going
• Reviewed RFCs and found a shortlist of "soon to expire" ones. A nudge email will be sent to the RFC sponsors.

• We talked about announcing the deprecation of smartmatch. We will work on wording for a new post and send that out soon, outlining our current plans.
• Paul has a (draft) PR to ad…

We're trying out new ways to send out these regular announcements of what we get up to on the Perl Steering Council. This will be a regular posting that gives a brief summary of what we discussed in our weekly (or at least, near-weekly, give or take scheduling clashes) meetings.

• Internals docs (such as perlguts, perlapi) could be done better, but it's unclear how. Some new documents might be useful, but there's a risk of spending too much time on obscure internal specifics that almost nobody will ever need to read about or touch.
• Smartmatch deprecation…

There is nothing like looking, if you want to find something. -- The Hobbit, iv, "Over Hill and Under Hill"

Recently on the p5p mailing list the topic of removing smart match re-surfaced. There was a fairly vigorous discussion about the effect this would have on CPAN. So I thought I would look into how many uses there actually were.

Fortunately there are Perl Critic policies for this: Jan Holčapek's Perl::Critic::Policy::ControlStructures::ProhibitSwitch…

Perl has had experimental features ever since I started using it at about version 5.6. These were things that were considered useful, but about which there was doubt -- about their final form, whether a satisfactory implementation existed, or whatever.

Until Perl 5.18, experimental features were simply documented as experimental. At that point, an experimental warning category was added, with sub-categories experimental::lexical_subs, experimental::lexical_topic, ="prettyprint…

The first task of last week's Weekly Challenge

0, 0, 1, 0, 2, 0, 2, 2, 1, 6, 0, 5, 0, 2, 6, 5, 4, 0,...

The first challenge is to understand just what van Eck's sequence is,
as the various online explanations are less than instantly helpful.

Van Eck's sequence is a list of integers starting at zero, where the next number
in the sequence is given by the distance between the current number
and the nea…

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past month.

Enjoy!

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past month.

Enjoy!

What happened?

In the latest development release of perl, smartmatch changed quite a bit.

Almost everything you believed about smartmatching is now wrong

No really, everything. All previous rules are gone except a single one: you can smartmatch against any object that overloads smartmatching (the only "objects" that overload them out of the box are qr// regexps).

Matching against a scalar value? Gone. Matching against a list of values? Also gone.

when is no more.

The when keyword is gone, split into two keywords: whereis and whereso; one smartmatches the value against the current subject and the other does a simple boolean check much like if. I'll let you guess which is which. This split is for good reasons (when sometimes does one and sometimes the other, sometimes depending on things like optimizations), but that doesn't make this any more intuitive.

use 5.010/use 5.028 won't guard you from this.

It would have been possible to support both behaviors, because the old behavior is already using feature.pm. In fact one could even enable old and new style when at the same time in a scope without problems. None of this was done though.

My suggestions

new smartmatch should be more useful.

Right now one can't do anything with it without a helper library (like my Smart::Match). That's just silly.

The insanity of old style matching was that the overloads depended on both operands, this gave rise to hard to predict behavior, but that doesn't mean one can't define useful behavior that only depends on the right side that follows the most common use-cases. In particular matching scalars stringwise, and making $foo ~~ ["bar", "baz" ] mean $foo in [ "bar", "baz" ].

This should be opt-in

Despite retroactively adding warnings the feature is experimental, it has become a widely used feature. This change is breaking a (yet unknown but significant) number of CPAN modules, and likely much more code in darkpan. Breaking this unless strictly necessary is dumb.

And it isn't necessary. We can easily only enable the new behavior when asked for. That way we can improve smartmatching without breaking a decade worth of smartmatching code.

We need better words

whereso and whereis are way too confusing. I'm not sure what that would look like but this just doesn't cut it.

Above all, we need a better process

Somehow, p5p made a fundamental breaking change to the language without even trying to involve the wider community. This blogpost shouldn't have been the first time the wider community hears about it. And we need that wider community IMHO because no one on p5p (myself included) has the kind of language design talent that's required to do the sort of thing we did here. I don't know what the solution would look like exactly, but I like this process even less than I like the outcome so far. I must admit I'm somewhat jealous of Python's PEP process, though I'm not sure that would work without a language designer to guide it.

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past two weeks.

Enjoy!