Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
From: Felipe Gasper
June 26, 2020 10:29
Re: Announcing Perl 7
Message ID: 56FAE988-461C-45EC-96CB-1F7A01C176F7@felipegasper.com
I think Darin’s idea sounds interesting: have both “perl” and “perl7” binaries, with the latter defaulting to the new goodnesses.
Maybe perl7 could have “use legacy Ancient::CPAN::Module” to preserve CPAN compatibility?
> On Jun 26, 2020, at 01:10, Darin McBride <email@example.com> wrote:
> I'll also agree with efforts to revitalise the community and language, and take similar issue to the previous points.
> I don't think the defaults for .pl, .pm, or non-extension files can change. However, .pl7 and .pm7 files could default to perl 7 features. Hopefully including warnings.
> Otherwise, I don't see a world in which I would be happy that my distro upgraded its perl to perl7 on me. It would break all my other stuff that I'm running. And likely would break every perl script that comes with the system, which means they wouldn't be able to upgrade to perl7 anyway once cups et al stopped working.
> If the executable is going to be /usr/bin/perl, it should run perl without breaking everything. If it's going to be /usr/bin/p7, then, sure, whatever, perl and p7 can coexist.
> I don't want to see another python2-to-3 migration. My distro is still trying to get past that one.
>> On Thu, Jun 25, 2020 at 10:48 AM Dan Book <firstname.lastname@example.org> wrote:
>>> On Thu, Jun 25, 2020 at 4:16 AM Dave Mitchell <email@example.com> wrote:
>>> On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:
>>> > * Major versions will be used for two purposes: 1. Turn on features
>>> > and pragmas by default, 2. Remove syntax from the language.
>>> I want to be on the record that I extremely strongly oppose this change.
>>> I think if people want to use the new modern perl, they just put this
>>> one simple line at the top of their code:
>>> use v7;
>>> this makes everything forward and backwards compatible, and eases the
>>> transition. The thing is that old perl binaries back to at least 5.8.x
>>> recognise this syntax and will produce a helpful error message:
>>> $ perl589 -e'use v7'
>>> Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1.
>>> this helps everyone: writers of perl7 code will know what the problem
>>> is when they accidentally run their code on an old perl binary, rather
>>> than getting some obscure error message.
>>> Older code continues to run without modification - you don't
>>> have edit every source file to add a 'use compat::perl5' line.
>>> You don't have to update every existing perl installation to add the
>>> compat::perl5 module just so that existing code will continue to run.
>>> CPAN continues to work.
>>> 'use v7' also allows the new stuff to be scoped to a single source file;
>>> other .pm files can still be included unmodified using the old perl
>>> Look, we've got this great built-in mechanism, 'use vx.y.z' that's been
>>> around forever. It hasn't seen much use yet, because frankly there's
>>> been very little call for it, since there hasn't been much new
>>> non-backcompat stuff so far. But its been sitting there waiting for use to
>>> use it.
>>> In 5 years or whatever, it will also save our bacon when perl8 is
>>> released; suddenly all that source code with 'use v7;' at the top will
>>> continue to work on the perl8 interpreter running in perl7 mode. Rather
>>> than suddenly all breaking.
>>> It helps IDEs as well - now they can look at a source file and know
>>> instantly what major release of perl this file was written against, and
>>> so how to syntax highlight etc.
>>> So 'use v7' benefits *everyone*: the crusty old coders and the shiny new
>>> coders who know nothing about older perl versions. It's a win-win.
>>> I've seen it suggested that not making v7 the default in some fashion
>>> continues to shackle us an overbearing commitment to backwards
>>> compatibility; but I really can't see this - if I'm missing something
>>> please explain it to me.
>>> Given that the v7 release of the perl interpreter will still have to
>>> support both old and new syntax/semantics regardless (so that whatever
>>> internal flags 'use compat::perl5' sets in the interpreter can suitably
>>> alter the behaviour of the lexer and parser), the choice of default makes
>>> no difference to how hard it is to maintain the interpreter.
>>> In fact by far the biggest issue with backwards compatibility in the
>>> interpreter is XS code, especially XS code which relies on stuff outside
>>> the API (or where its not clear whether its API or not). Nothing in the
>>> perl7 proposal (as far as I'm aware) fixes this - it will still be by far
>>> the biggest millstone around our necks in terms of maintaining and
>>> improving the interpreter.
>>> One of the few remaining selling points of perl5 has been the good
>>> backwards compatibility we've offered. If I were a programmer or company
>>> considering investing in perl for the first time, being told that
>>> my effort now won't get broken in 5-10 years time sounds like a good
>>> thing. If not, I might as well invest in one of the other shiny new
>>> languages with no long-term backcompat guarantee.
>>> To be clear, I am completely happy for a bump in version number to 7;
>>> I just want the default behaviour to be as before in the absence of
>>> 'use v7'.
>> I agree with all points raised here. I think it is a bit of wishful thinking (?) to equate "nobody knows individual features" with "nobody uses feature bundles". The feature bundle, to me, is the exact mechanism that we should be using to solve this problem - it immediately and unambiguously sets a new lexical base to work with. The major problem so far is that since v5.12 it has also enabled strict, but it has yet to enable warnings, meaning any modern code has to also enable warnings, thus generally not making things any simpler than just enabling strict and warnings yourself and ignoring the features you don't need.
>> On top of that, I am not sure what having those features available by default improves for visibility of them. I only have the benefit of my own experience, but I cannot think of a case where I did not use a feature bundle, where I would also be able to update to such a Perl 7 in this decade. To lay it out, I have three kinds of projects: CPAN, hobby, and work-related. My CPAN projects support anywhere between 5.8 and 5.16 as a minimum version depending what is required for them to function. These obviously cannot take any advantage of either newer feature bundles or Perl 7. My hobby projects currently use the 5.20 feature bundle most commonly, plus warnings. These easily would use the v7 feature bundle if it existed, regardless of whether it was default or not. My work project only cares about the version of Perl it is currently running on, so again, would easily use the v7 feature bundle once it was planned to run on Perl 7, regardless of whether it was default or not; and until that point of course would have no reason to.
>> The other main issue I have is this argument that we are expending a lot of effort to cater to this old code. Sure, but this incompatibility does nothing to solve that. The old features still have to be supported and deprecated the exact same way as in our current mechanisms. And this is just pure perl, as mentioned there is no change to how XS APIs are managed.
>> I also agree that a major version is an extremely important step in terms of perception, marketing, and visibility. And making it easy to get modern defaults is an endless personal goal of mine. But I don't think the incompatibility as proposed provides a benefit worth the cost, when we have not even explored making feature bundles "complete" by enabling warnings, or further encouraging their use.