Front page | perl.perl5.porters |
Postings from July 2020
Re: Perl 7 - updates
From: Philip R Brenan
July 5, 2020 17:40
Re: Perl 7 - updates
Message ID: CALhwFRkm3K4r4UdXfwE8yEQcxO38-a_kp=TGf7uSpGHYA9VTeA@mail.gmail.com
If it cannot run all of CPAN, out of the box, by default, now and forever,
with no tweaking whatsoever, then I cannot say that it is Perl: it must be
*another* language. If I have to port all of my CPAN modules to *another*
language, then it probably should be *some*-*other* language.
I propose that every future change be controlled by pragmata. Pragmata can
be bundled. Each user could set their own local defaults in a file.
Modules would have to say explicitly what new features they want so that
compatibility with CPAN, as it exists today, is always guaranteed. Pragmata
would allow individual users to fine tune the language to their specific
needs. Such a unique capability would put Perl back on the cutting edge of
language development. With sigils or without? By your pragmatic command.
There are far too many compelling reasons not to use Perl. There is only
one good one: CPAN. At the moment, CPAN, alone, stands between Perl and
oblivion. Using pragmata effectively we can modernize Perl and at the same
time retain CPAN in all its glory, now and forever. Please: write the few
lines of code necessary to make this happen rather than expecting the
entire user base to upgrade decades of work to achieve the same effect.
On Sat, Jul 4, 2020 at 12:26 AM 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,
Philip R Brenan <https://metacpan.org/author/PRBRENAN>