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

Re: Announcing Perl 7 Perl5 Porters <perl5-porters@perl.org>

Thread Previous | Thread Next
From:
Salvador Fandiño
Date:
July 1, 2020 11:18
Subject:
Re: Announcing Perl 7 Perl5 Porters <perl5-porters@perl.org>
Message ID:
cdc3b64f-60d6-4767-1a12-696e262ff948@gmail.com
On 1/7/20 1:16, Darren Duncan wrote:
> On 2020-06-30 3:02 a.m., Salvador Fandiño wrote:
>> On 30/6/20 6:40, Darren Duncan wrote:
>>> Having taken more time to think about this, and seeing more 
>>> discussion, I have come around further towards supporting a key 
>>> aspect of Sawyer's proposal.
>>>
>>> 1. I no longer believe that a v7+ Perl interpreter should consider it 
>>> mandatory for each Perl file to start with a "use <version>;" and 
>>> instead I take the position that using such declarations should just 
>>> be strongly encouraged, particularly for any Perl code meant to be 
>>> shared with others.
>>
>> But the thing is, some newbie writes a script in the all new perl 7 
>> and doesn't start it with the "use v7;" line. It works, everything is 
>> fine.
>>
>> A couple of years into the future, a new release of Perl with some 
>> incompatible changes is ready, perl 8. You follow the same logic: "use 
>> v8;" is not mandatory, new features are enabled by default and so, a 
>> good bunch of perl 7 scripts and modules become broken, and people is 
>> forced to change then adding a "use compact::perl7" line?
> 
> I strongly disagree with "compat::perl7"; what they should be doing then 
> is adding "use v7;" which is the exact same thing they could have added 
> before but didn't, and that would still work on Perl 7.

Well, that compat::perl7 thing was mostly a joke, not a serious 
suggestion!!!

What I was trying to emphasize is that unless you explicitly declare the 
perl version semantics you want to use in some way (and I am 
definitively in the "use v7" camp here), your code would become broken 
in the next mayor release, if that follows an 
all-features-enabled-by-default policy.

In the end what I am trying to show here is that an 
all-features-enabled-by-default policy is broken unless you admit it 
would be ok to force everybody to revise *all its code* every time a new 
mayor version comes out, just to ensure that it remains compatible with 
the new features added to the language.

So, it doesn't make sense for perl7 and it will not make sense for 
perl8, etc.

> 
>> It doesn't makes sense to me.
>>
>> It you want to avoid the "use v7;" line, then you should be able to 
>> tell perl explicitly in some way you want the 7 semantics. The only 
>> sane way I can see for that, is using different file terminations. 
>> I.e. p7, pl7, pm7, t7.
>>
>> And when perl 8 comes out, you can switch to p8, pl8, etc.
> 
> I typically consider that adding new version-specific filename 
> extensions is a horrible idea.  I hated the .pl6/.p6 extensions (.raku 
> was so much better) and I hate the idea of pl7 etc.  Stick to .pl/.pm 
> and recognize versions by the contents of the files.

Just to be clear, I don't particularly like that either. I think the 
best way to enable p7 semantics is to require the "use v7" line.

That was just an alternative in case the "use v7" option is completely 
ruled out.

Also, note that both solutions are not incompatible.

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