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

Re: Perl 7 - updates

Thread Previous | Thread Next
Darren Duncan
July 4, 2020 00:14
Re: Perl 7 - updates
Message ID:


What you've laid out here is essentially 100% what I was proposing in my 
arguments, that the "use v" is mandatory and that its purpose is to communicate 
the standard or protocol that the Perl code implements.

With this, Perl 7+ has a much rosier future!

I didn't seem to get much acknowledgement back then, but I can see this has been 
given strong support now.

Unlike myself, I feel that you explained what I meant much more succinctly.

One of the key features of this, that I consider important, is invariance over 
time or interpreters.  That means Perl 5/7/8/etc all follow the same rules and 
requirements.  That means when you have a given piece of Perl code having a "use 
v" it will run the same on any interpreter that allows it to run at all, and the 
behavior you get is specified the same way the whole time.  In contrast is the 
bad way involving "compat" for prior versions and nothing for current, its a 
constantly rolling or changing requirement or behavior for the same code.

Regarding the binary, I propose that option 2 is best, the "perl$foo" option.

The way I see it, "Perl 7" isn't so much about that version as that it is about 
a new contract with the user on what they can expect regarding features and 

The number 7 etc should never appear in filenames, just the "use v" line or 
documentation or distro metadata and such.  We want something we can keep using 
as Perl goes to 8 and 9 and so on.

On a related note, I suggest we start bikeshedding about branding together with 
the suggested binary name and probably make them the same.  Just as we may call 
the binary "perl$foo" maybe we should also mark this generation of perl as "Perl 
$Foo" rather than "Perl 7".  We happen to use version number 7 but don't make 
that the branding.

I am purposefully avoiding making any $Foo suggestions here as that would better 
be in its own thread.

Thank you again!  Big ++ from me here!

-- Darren Duncan

On 2020-07-03 4:25 p.m., Sawyer X wrote:
> Hi,
> 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 conformity.)
> * 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 features.
> * 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 supported:
>      * "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,
> Sawyer.

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