develooper Front page | perl.perl5.porters | Postings from July 2020

Perl 7 - updates

Thread Next
Sawyer X
July 3, 2020 23:25
Perl 7 - updates
Message ID:

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 
version 8".)
* 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.

Thank you,

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About