Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Dan Book
Date:
June 25, 2020 16:48
Subject:
Re: Announcing Perl 7
Message ID:
CABMkAVW-hs_v_nkKqNN_LtgKeJHbKE37Hm22GjwQfvoY=ziXgQ@mail.gmail.com
On Thu, Jun 25, 2020 at 4:16 AM Dave Mitchell <davem@iabyn.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
> syntax.
>
> 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.
-Dan
Thread Previous
|
Thread Next