Front page | perl.perl5.porters |
Postings from July 2020
Re: Perl 7 - updates
From: Dan Book
July 4, 2020 16:02
Re: Perl 7 - updates
Message ID: CABMkAVVf3BL9pT2n6UkYhUtZvfccXHfxKjyj968BT6jsaL2KgA@mail.gmail.com
On Fri, Jul 3, 2020 at 7:26 PM Sawyer X <firstname.lastname@example.org> wrote:
> 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
> 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 for reconsidering the direction of the plan. I think there are
still things that need to be ironed out here (and I see that interesting
discussions around that have already started), but it certainly addresses
my most significant concerns, in that it encourages explicitness rather
than silent behavioral change.