Front page | perl.perl5.porters |
Postings from May 2022
Wherefore art thou Perl 7?
Thread Next
From:
Neil Bowers
Date:
May 21, 2022 08:37
Subject:
Wherefore art thou Perl 7?
Message ID:
7e7071f1-dd8c-4539-ba5a-da067aa9b686@Spark
Over the last year or so, we (the PSC) have occasionally had questions along the line of "so, whenâs Perl 7 coming out then?". With 5.36 imminent, weâve seen an uptick in these. We thought that had been addressed, but looking back over discussions here, there was no single email or set of meeting notes that summarised the meta-plan for Perl that we (p5p) hammered out a year ago. Various parts of the plan were worked out at different stages.
We plan to publish the following as a blog post, to make it easier to refer people to, but we wanted to post a draft here for comment / iteration.
Neil
Wherefore art thou Perl 7?
With Perl 5.36.0 just around the corner, we thought that this is a good time to clarify plans for the future of the Perl programming language. We realised that the future was hammered out in a number of steps, across several months. This meant that there hasn't been a single statement we could refer people to. This post is to fill that gap.
Two years ago Perl 7 was announced. A key idea for Perl 7 was to significantly reduce the boilerplate needed at the top of your code, by enabling a lot of widely used modules / pragmas, but this would have come at the price of breaking some backwards compatibility. This would have meant that some existing code wouldn't have worked without modification.
This prompted a lot of heated discussions: some thought this was a great idea, and some thought it a terrible idea to throw away one of Perl's key strengths. Ultimately this led to a discussion about who had the right to make this decision, now that Larry is no longer involved in Perl (and hasn't been for about 20 years). The end result of all those discussions was a new governance structure: the Perl 5 Porters ("p5p") mailing list is still where the future of Perl is discussed, and we aim to build consensus, but where that's not possible, the three-person Perl Steering Council (PSC) has ultimate decision making authority on the future of Perl. The PSC is elected annually by the core team (the subset of p5p who have contributed most to Perl "recently").
The first PSC was elected in late 2020, and one of our first tasks was to create a plan for the future of Perl, and to put that in motion. A lot of discussion and iteration followed, but the strategy we agreed is:
Existing sensibly-written Perl 5 code should continue to run under future releases of Perl. Sometimes this won't be possible, for example if a security bug requires a change that breaks backward compatibility.
We want to drive the language forwards, increasing the rate at which new features are introduced. This resulted in the introduction of the RFC process, which anyone can use to propose language changes.
We want to make it easy for people to use these new features, want to do what we can to encourage their adoption.
At the heart of this strategy are feature guards and version bundles.
Features
If a new language feature isn't backwards compatible, then it is protected with a feature guard. For example, Perl 5.010 introduced the `say` keyword. But it couldn't be enabled by default, as someone might have a say function in their code, which it would conflict with. So if you want to use say, you have to request that feature:
   use feature 'say';
   say "hello, world";
Experimental features
Sometimes a feature will be marked as experimental, which means that we're not sure whether it's in the final form, and we'd like people to play with it and give feedback. The experimental status means that we reserve the right to change everything about it in a subsequent release, or even to remove it. If you use such a feature, you'll get a warning, which you can suppress with an extra line of code:
   use feature 'signatures';
   no warnings "experimental::signatures";
   sub add ($a,$b) { return $a + $b; }
In general you shouldn't use experimental features in production code.
Version bundles
A lot of features have been added since 5.10.0, and a bunch more have been added in 5.36.0. That can mean that you end up putting a lot of `use â¦` lines at the top of all your code. Instead, you can enable all the features provided in Perl 5.36.0 that weren't included in the original Perl 5 release, with just put this one line at the top of your code:
   use v5.36;
This does three things: (1) it tells the perl interpreter (and human readers), that your code requires perl 5.36.0 or later to run; (2) it enables all additional non-experimental features provided by Perl, and (3) it uses a number of additional pragmas that have been accepted as good practice.
That one line is equivalent to:
   require v5.36;
   use strict;
   use warnings;
   use feature 'say';
   use feature 'state';
   use feature 'current_sub';
   use feature 'fc';
   use feature 'lexical_subs';
   use feature 'signatures';
   use feature 'isa';
   use feature 'try';
   ⦠and a whole lot more â¦
Code that starts with `use v5.36` will run against future versions of Perl â all versions of Perl know about the version bundles of previous versions of Perl.
Version bundles have two main benefits: (1) they greatly reduce the boilerplate you have to write at the top of your code, and (2) they document what version of Perl your code was written to. Version bundles have been supported since 5.10.0, but not widely understood or used. With the release of 5.36 we hope to change that.
We have a lot more proposals in the pipeline, including the introduction of richer OO syntax. We expect 5.38 to include another swathe of new features.
What about Perl 7?
For now, our plan is to continue introducing new features and to resolve all existing experimental features, so they're either dropped, or become non-experimental features (i.e. included in the version bundle).
The downside with this is that people often can't remember which version of Perl introduced which feature(s).
At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0. Annual releases would continue, so it would then be followed by 7.2, 7.4, etc. We have a lot of good ideas in the works, and if we can keep up the momentum of the last year, then things are looking promising. And in the meantime we'll continue with 5.XX releases.
Thread Next
-
Wherefore art thou Perl 7?
by Neil Bowers