Re: Announcing Perl 7

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

Thread Previous | Thread Next

From:

Branislav Zahradník

Date:

June 29, 2020 06:55

Subject:

Re: Announcing Perl 7

Message ID:

CAB=rbO=c2Y0DzyCOAtL8GVTMDmWBGU+szJa8JNQ_CkefHOYeqg@mail.gmail.com

First let me state I do not oppose the whole effort.
I totally agree with Sawyer's effort evaluation as presented on CiC.
I disagree with the distribution of present and future costs of active
and new users (as I perceive it) .

* Predictability and continuity

Defining next release as an old release + some features by default can
become a great advantage of language, easy to advertise.

I'd go further with extending definition of feature live cycle,
- release X - feature enabled by default
- release X+1 - feature disable will be available but deprecated
- release X+2 - get rid of trash

This can add a great value in the predictability of language development.

This may slow down some improvements but I believe that focus on TCO is the
future of perl.

We should learn from known mistakes, failures, and good examples especially
in
this topic.

* "nobody knows individual features"

RFC idea: what about preparing eg [Anki][https://ankiweb.net] flashcard deck
with all capabilities, features and deprecations? With good design (based on
POD) it may be available for CPAN modules as well.

* Compile-time defaults

Difference between X and X+1 should may also suggest different compile time
default values. This process should be defined, with continuity in mind as
well.

* Language version specification

David Mitchell has a good point about "use v7".

Extending Philippe Bruhat's idea of mandatory version spec with behaviour:
- "no vX" will pass also on v(X+1) and v(X+2) and will disable all necessary
  features with respective deprecation notes
- "use vX" will pass also on v(X-1) and will allow all necessary features
- "use vX" should pass also in v(X-2), at least turning on deprecation and
  removal of known features (maybe via new pragma?)

Such an arrangement will allow users to use newer binary with predictable
behaviour. It will also allow simple grep based mechanisms to monitor
progress. Again, great value to propagate, stressing on language continuous
development and its predictability.

If will also allow to continue development in single code base (though I
agree
that current perl5 code base is not in optimal shape)

Ad Sawyer's note: "use statement needs to be added by someone"

Apart from the fact that this change can be done by script, this change is
one-time change. Assuming suggestions from this summary will be adapted this
change will decrease future maintenance.

Ad: "use v" turns on *everything* till this version

Unique time to change it is now. Eg "till this version in this major
version"

Ad: Vadim Konovalov's "Are there any modern languages that require some
version"

Every language requires some version, but for whole project via tooling
configuration. Ability to specify exact version in source code allows you to
adapt a new revision of language before you'll adapt the whole code base.

* "To release 5.32.0 as 7 would be a mistake for many reasons"

(citing Karen Etheridge)

Definining 7.0.0 as 5.32.0 is IMHO good idea but is a pattern that should
be strictly followed, so for example 5.33.1 should become 7.1.1.

Anyway, I will rather use "perl 7 base line is 5.32.0".

* CPAN support

CPAN should somehow support also unmaintained module versions, eg (release
date order):
- Foo::Bar v1.00 is v5
- Foo::Bar v2.00 is v7
- Foo::Bar v1.10 is v5
- Foo::Bar v2.50 is v8
- Foo::Bar v1.20 is v5

People using unmainted versions of perl should still have access to CPAN
modules suitable for their version of perl as well as module maintainters
should be able to support such versions.

* ad Paul "LeoNerd" Evans' tidy/critic and try

This is a greater problem than just try/catch. This problem will affect
every
custom keyword and operator. IMHO the ability to extend language with DSL
will be
crucial language feature in 5-or-so years.

Offtopic: IMHO try/catch should remain in the module, only the CATCH
feature should be
provided by the language.




On Wed, 24 Jun 2020 at 22:49, Sawyer X <xsawyerx@gmail.com> 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:
> https://github.com/atoomic/perl
>
> 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] https://www.youtube.com/watch?v=6wPMh-3qYJM
>

Thread Previous | Thread Next