Front page | perl.perl5.porters |
Postings from July 2020
Perl 7 - updates
From: Sawyer X
July 3, 2020 23:25
Perl 7 - updates
Message ID: firstname.lastname@example.org
I think it impractical to respond to everyone on the original thread,
nor would it be visible enough to respond to one person with an update
and hoping everyone sees this.
So what happened since my original announcement:
1. A lot of people replied. Several mini-discussions ensued.
2. I read through the thread, every message, with a few pointed
responses but not more than one regarding the overall plan.
3. I've had several one-on-one conversations with people who wanted to
talk about things more directly and synchronously.
4. I've looked at all the options we have available and the problems raised.
I want to update you on the state of affairs at the moment.
On Perl 7 defaults:
Dave M's original email proposes using the "use v" to achieve what we
want with a single line. This option seems like a feasible solution. We
can view it not as "turn on the following features," but "this is the
standard of Perl I'm writing this file in." A few others also shared
this idea on the list. I think it does make sense.
However, to work, it would require the following stipulations:
* It will be mandatory. Every file running Perl 7+ binaries will need to
indicate which standard or protocol it implements. ("Standard" and
"protocol" here do not refer to any technical definition for us. I'm
using them as terms in English to express the idea of the code's
* Each version will support only three "protocols": Previous, Current,
and Next. In this sense, Perl 7 will support "use v5", "use v7", and
"use v8". This will make the code able to progress in different ways,
but not left too far behind. It will also allow eventually removing
* We will change "use v" to be explicitly about turning on the features
we wish to have in this version. It will no longer be "turn on everything."
* "use VERSION" will need to change its meaning from "use this minimum
version" to "use this protocol" so it could support protocols we make
defaults in the next version.
To summarize, the changes mentioned here are to essentially:
* Use "use VERSION" instead of "use compat::perlX".
* Change "use VERSION" to mean "protocol," so "use v8" on Perl 7 will
work. (It's effectively "give me version 8" or "I'm writing for protocol
* Make this mechanism required by the user in future binaries.
At first, I did object to this. This is because the goal, as stated by
others on the list as well, I wanted zero entry barrier to beginners.
While I think any obstacle is not the optimal behavior for a beginner,
having a single line that is required is much more feasible and
maintainable. This is because of the concept of the "protocol" (or
whichever more accurate term we go with) to say that you're coding for a
particular version or set of Perl features, and because making it
required means it will *definitely* be there.
It is important to note that with this change, we can provide helpful
feedback for the user. If one were to run a newer binary with no "use
VERSION", we could produce an output that says:
You need to provide the version of Perl your code targets. This is
done with a "use V<version number>". The following version numbers are
* "use v5": Perl 5 behavior - the previous version.
* "use v7": Perl 7 behavior - the current version.
* "use v8": Perl 8 behavior - the next version.
Please pick and add one of these lines to the beginning of your code.
... or something to that effect. This can make it trivial to understand
and add. Each version will show which versions it supports so you know
what you can do. We could also explain (or include links to) which
features each version has.
On Perl 7 binaries:
We do not own /usr/bin/perl but we do produce binaries and provide
suggestions for distributions (which they are free to ignore, of course).
I think we have three major options with binaries:
1. We can produce a "perl7" binary and recommend to distributions this
be "/usr/bin/perl7". The benefit is clear: Existing users change nothing
and will continue to stay on Perl 5 until they decide to change their
shebang, command line, or the distribution fixes enough to, by default,
point "/usr/bin/perl" to it. The downside is all-new developers, or
those that want to move to the next version, will need to use a new
shebang, a new command line, and basically, we're forcing them to pay a
cost they might not.
2. We can produce a different binary, "perl$foo". This is similar to #1,
except this can be a rolling binary like "perl" is. It's one less dance
for distributions between symlinks, though it might be even harder on
them. The additional problem with that is that it essentially "forks"
the binary name for Perl. I would hard-pressed to find a suitable name,
but it's worth bikeshedding. The confusion for beginners would grow with
this option, though. Over time, it might be a better option.
3. We continue to produce a "perl" binary and recommend distributions to
change the Perl 5 binary to be "/usr/bin/perl5". This is the opposite of
#1 and puts the entire weight on existing code.
We should discuss these options, as well.
There are additional topics to discuss, regardless of what I've written
about. Namely, Karl and others requested the next steps, what we do, and
how. I want to post a separate message about that and start preparing
our GitHub repository for that.
We also need to talk about CPAN and see what mitigations we need and
how. I know there's progress on this front, and I think the right people
should report on it.
Perl 7 - updates
by Sawyer X