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

Re: Announcing Perl 7

Thread Previous | Thread Next
From:
Darren Duncan
Date:
July 1, 2020 03:13
Subject:
Re: Announcing Perl 7
Message ID:
cde9ec17-5e9b-9af3-d49b-629c528a0a20@darrenduncan.net
On 2020-06-30 5:06 p.m., Rocco Caputo wrote:
> On 06/30/2020 19:23, Darren Duncan wrote:
>> I am operating under the assumption here that it is possible and sufficiently 
>> easy to write Perl code that is compatible with both Perl 5 and Perl 7+ at the 
>> same time.  The vast majority of syntax should be in the common subset of both 
>> versions, and when one writes to that both should just work.  So "fix" means 
>> ensure just the common subset is used.  I want a single CPAN to work for both 
>> versions. -- Darren Duncan
> 
> Given that perl7 is to be unshackled from perl5 compatibility, it's not 
> unreasonable to expect that the "common subset" that fixed CPAN modules may use 
> will shrink over time.  Modules wishing to use both languages will occasionally 
> break and be required to re-evaluate whether to continue being compatible with 
> one language or the other.  Those that continue to choose both may need to pare 
> down their use of language features to remain within the shrinking common subset.

Yes, it is as you say, but that's not a problem.

For the next year at least, the common subset is mostly just what you get when 
you have followed what is best practices anyway for Perl 5 code.  Those who 
already do this are most of the way there, and otherwise getting them there best 
is doing this.  So to get the Perl 5 and Perl 7 overlap is mostly just following 
best practices.

That means Perl code that satisfies use-strict and use-warnings and doesn't use 
indirect notation and doesn't use bareword filehandles and so on.

Certain experimental things like routine signatures or smart match would be 
avoided for the maximal coverage, say if you want to work with everything from 
5.008 thru 7+, which is what I would be doing with my CPAN projects for awhile.

If one wants to use routine signatures, then their best bet is probably to "use 
Perl 5.28" or whatever introduced the current version of that and had the last 
breaking change.  Then one has the greatest Perl language feature set to use 
that is still nominally both Perl 5 and Perl 7+.

In general, best practice for CPAN modules is to explicitly have "use N;" to 
indicate the lower bound of the total set of Perl versions that provides the 
language features they want to use, and over time they gradually increase that 
lower bound as they want to use more features.

But the point is, subject to each developer making their own choice on what they 
want to support, it is very doable for an extended period to use a langauage 
subset that at least overlaps with SOME versions of Perl 5.

The real trouble will come when/if Perl evolves so much that the common subset 
of that and Perl 5.32.0 is uselessly small, but even with a lot of freedom to 
evolve I doubt that will happen for quite awhile.

-- Darren Duncan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About