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

Re: Announcing Perl 7

Thread Previous | Thread Next
Eric Brine
June 29, 2020 22:59
Re: Announcing Perl 7
Message ID:

we tried to write down all the things that we enable that to us is a good
> baseline for Perl. That list I think was around 8 to 10 lines.

It takes far more than that to write a portable script that handles STDIN,
STDOUT, STDERR and @ARGV correctly.

See (and that still doesn't
handle @ARGV correctly on Windows).[1]

Sawyer X speaks of making it easy to accept newcomers, and I think one of
the biggest difficulties facing newcomers is dealing with encoding and
decoding. Did you know every single builtin function (named operator) that
deals with file names still suffers from The Unicode Bug?[2] And did you
know it's impossible to use the builtin functions to access files in

It seems to me this area would be a great area for improvement for Perl 8.
I've been tossing around plans for this in my head for a while, but
uncertainties in my life have detracted me from working on this.

- Eric "ikegami" Brine

1. Unless the command line happens to be limited to characters in the
intersection of the OEM Code Page character set and the Active Code Page
character set.
2. Demonstration found below.
3. Unless the file names happen to be limited to characters in the Active
Code Page character set.

$ perl -e'
   { my $f = chr(0xE9); utf8::downgrade($f); open(my $fh, ">", $f) or
warn($!); }
   { my $f = chr(0xE9); utf8::upgrade($f);   open(my $fh, ">", $f) or
warn($!); }

$ dir
total 0
-rw------- 1 ikegami ikegami 0 Jun 29 18:54 é
-rw------- 1 ikegami ikegami 0 Jun 29 18:54 �

On Wed, Jun 24, 2020 at 4:49 PM Sawyer X <> wrote:

> Hi everyone,
> A little while ago, I gave a talk[1] at The Perl Conference in the
> Cloud where I covered the Plan for Perl that includes the following
> significant changes:
> * We will begin using major versions again, starting with version 7.
> * Major versions will be used for two purposes: 1. Turn on features
> and pragmas by default, 2. Remove syntax from the language.
> * Features will be guarded within a major version (that is, one *must*
> enable new features in 7.x with "use feature") but will be turned on
> in the next major version.
> * Perl 7.0.0 will be the first release. It will effectively be 5.32.0
> with a small number of pragmas (at the very least, strict and
> warnings) and features. The goal is to make it as trivial as possible
> to upgrade from 5.32.0 to 7.0.0.
> * Perl 5 will enter a long-term support window - 5+ years. Exact
> number not determined yet.
> * We intend to release 7.0.0 within a year. However, I am setting the
> goal of releasing it before the end of this year. I want to pave the
> way for 7.1.0, which will have the stable release of 7.2.0.
> * We will introduce utilities to help upgrade code to Perl 7. For
> example, if we were to add signatures by default in 7.0.0 (only *for
> example*), we will need code that helps users rewrite "sub foo ($)" as
> "sub foo :prototype($)".
> * We will also introduce a "compat::perl5" module, which will turn
> back the defaults of pragmas and features on 5.32.0. With this change,
> one could upgrade to Perl 7 binary immediately without changing the
> code. It allows a longer upgrade path.
> * We will also introduce a module to help fix up other modules. Such a
> module will especially help toolchain and infrastructure for CPAN
> manage the automatic upgrade or downgrade of modules without the user
> having to fix the code they are installing if it's incompatible.
> It would be hard to repeat everything in the talk, so I recommend
> watching the talk. The short and sweet is: We need to prioritize users
> who *write* Perl versus users who explicitly refuse or cannot update
> their code. In our current prioritization, we force all existing users
> and new users to manage the technical debt of previous generations.
> There is *a lot* to figure out at this point. We need to:
> * Update the internal code to support "use strict" and "use warnings".
> * Bump to 7.0.0.
> * Determine which pragmas and features will be enabled and turned on.
> * Determine how long we will support Perl version 5.
> * Determine the criteria for bumping major versions. Time might not be
> the best metric.
> * Create tickets for issues to be done so that the community could
> help. (People have already reached out, wanting to support this
> effort.)
> * Make sure we clarify what gets backported to Perl 5.32.x. Right now,
> it's the same criteria as every other maint release, except for a much
> longer time-frame.
> * Work on moving to 7.0.0 is already underway on the p7 branch here:
> Additional comments:
> * Yearly releases for minor versions will continue as planned.
> * Monthly releases for dev versions will continue as planned.
> * See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.
> 7.2.0 will be akin to 5.34.0.
> * As exciting as 7.0.0 will be, it will mostly be there just to put us
> on our path. 8.0.0 will likely be much exciting.
> * There are notable stakeholders to the language which will be working
> with us to update their code to 7.0.0 defaults, to help understand the
> possible consequences.
> * We will need to rename the GitHub repo. That's okay because GitHub
> creates an automatic redirect for the URLs, including the GitHub clone
> paths.
> * /usr/bin/perl is owned by distributions. We are not in charge of it.
> We will be providing support to vendors and distributions and help
> them reach good decisions and move forward in the manner they choose.
> I apologize for not sharing this news earlier. We have been working on
> this plan for a very long time. p5p is a public mailing list, and we
> needed to manage the communication around this. Despite not being
> public, many people worked on it. Vital core developers, numerous core
> contributors, several significant stakeholders, vendors/distributions,
> and people with an in-depth history in Perl and the core code - were
> all involved. We have done a *lot* of work to get to where we are.
> While it's not a fully detailed change proposal, we have gone through
> quite a lot and tried to be very thorough while leaving room for
> things to now be openly discussed.
> Several threads will likely begin on the list to address specific
> issues listed above. I imagine this thread will itself receive a lot
> of responses and soon become sprawling. To manage this, I will open
> several threads, over several weeks, so we could have "waves" of
> discussions, instead of one monster thread in which we might quickly
> lose both our place and our focus. When discussing these topics, I
> request people to communicate mindfully and constructively.
> I want to thank everyone who helped work on this plan and shape it
> into what it is today. These are too many people to mention, but I
> want you to know I appreciate the effort, the time, the thorough
> reviews, the feedback, the ideas, and the solutions.
> Sawyer.
> [1]

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