Front page | perl.perl5.porters |
Postings from July 2020
Re: Perl 7 - updates
Thread Previous
|
Thread Next
From:
Branislav Zahradník
Date:
July 4, 2020 04:31
Subject:
Re: Perl 7 - updates
Message ID:
CAB=rbOmbUPo=3KEDg1Yhyk15Ldu0qcuSWtRYH9VVqcJmiD=T9g@mail.gmail.com
On Sat, 4 Jul 2020 at 05:12, Branislav ZahradnÃk <happy.barney@gmail.com>
wrote:
>
>
> On Sat, 4 Jul 2020 at 01:26, Sawyer X <xsawyerx@gmail.com> 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.
>>
>
> This should be extended with feature life cycle definition.
>
> Using "Next protocol" is a little bit tricky, I'd use at least
> "Next-Preview"
> or something similar. Its full feature set is not known yet. What is known
> is only behaviour of features already known:
>
> - feature enabled by default in v7 will cause deprecation warning if
> disabled
> after seeing "use v8"
> - feature made mandatory in v7 will cause compilation error if disabled
> after
> seeing "use v8"
>
> * 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.
>>
>
> Every release of perl (starting with 7.0.0) should produce:
> - perl5
> - perl7
> - perl8-preview
>
> Why perl5:
> It will allow distributions to produce compatible packages. Imagine
> scenario
> when 8.0.0 will be released - there will be no more perl5 but there may be
> users
> refusing / not capable to move forward. This way they will have at least
> one latest
> version with well defined path / mechanism to upgrade.
>
> Why perl8-preview:
> As pointed out by others, v8 features will be frozen in future.
> Usage of perl8-preview will be mostly to test code base readiness in terms
> of not using old features as CI integration test, for example:
> - "use v7" will turn "no indirect" by default, allowing "use indirect"
> - "use v8" will print out deprecation warning "use indirect is deprecated"
> - later, perl9-preview with "use v9" will simply refuse to accept such code
>
Update regarding "use v8":
After reading other threads it seems to be that pattern "use v8; use v7;"
can be
used as a defensive pattern to eliminate and prevent reappearance of
features
already known to be deprecated / removed in v8
Update regarding v6:
imho v6 should be recognized as well and rejected with special error message
"Raku v6... requested, this is Perl vX.Y.Z"
>
>
> 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