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

Re: Dual-life perl 5-or-7 code and prototypes - impossible?

Thread Previous | Thread Next
Paul "LeoNerd" Evans
July 2, 2020 15:42
Re: Dual-life perl 5-or-7 code and prototypes - impossible?
Message ID:
On Wed, 1 Jul 2020 13:26:21 -0500
Todd Rinaldo <> wrote:

> > On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans
> > <> wrote:
> > 
> > On Wed, 1 Jul 2020 07:31:42 -0500
> > Todd Rinaldo <> wrote:
> >   
> >> I agree that's probably the best way to go. It's a technical debt
> >> that makes sense to put off for another day. The same goes for
> >> Test2 prototypes.  
> > 
> > Can we get you to say this again clearly, for the audience?  
> If you want me on record for something, I'll say I think dual life
> modules are a bad idea we had to do because perl 5 lasted so long.
> I'd rather we stop updating the CPAN version and keep what ships with
> Perl. I realize there are counter arguments to this and it's not the
> right time so ¯\_(ツ)_/¯ 

I am not just talking about dual-life modules, but any module that
lives on CPAN. For example lets take my List::UtilsBy:

Heavily used by a lot of other things down-river, and definitely
currently works before 5.20; probably back as far as 5.8 according to
the test matrix.

I have had an attempt at providing what I believe is my best effort at
fixing this; at providing something by which current perl 5 modules can
apply prototypes in a way that still works as valid perl 7 syntax:

Given the huge Caveats section, I am hesitant to even apply this to any
of my own modules.

> > Are you actually saying that every Perl 5 module should now be
> > actively defending itself against a future Perl 7 from causing it
> > breakage?  
> IMO a dual life (especially something in dist) should be written to
> work with the version in blead. The long tail of having to code down
> to the supporting a perl written 20 years ago is unsustainable. 

Yeah; no great complaints from me there.

But again I'm not talking about dual-life modules; I'm talking about
all of CPAN.

Under this current plan of forcing 7-semantics on any perl module
without it asking so under "use VERSION" means that every single
prototypes-using CPAN module will now be broken trying to run on
perl 7. That's a lot of modules.

> > And it should be doing so by guessing that 'signatures' is the one
> > and only feature that needs to be disabled?  
> It's not a guess right? you're using prototypes and the trick of
> rewriting the prototype means you can only be compatible back to perl
> 5.18. So we have to do this instead.
> no if $] >= 7 feature 'signatures';

And what if perl 7.2 decides that actually the keyword `sub` for
anonymous lambda functions is a bad idea, and we should all be spelling
it `lambda` instead? Does that mean now I have to go back around
everyone one of my CPAN modules that has ever created an anonymous
function and put

  no if $] >= 7.002, feature => "lambda";

This is, again, guessing about what future things a future perl will
require my existing code to defend against.

> > Are you going to promise that there won't be any more features in
> > the future that we'll also have to turn off?  
> I'm not promising anything. It is my hope that some day in the
> future, enough stuff moves off of 5 that the v5 protocol just gets
> dropped from support. Is that next year or next century? No idea. 

Next century is far off. The announcement was that we'd have perl 7
"within a year, hopefully within six months". This isn't a century-away
question. This is me worrying about a lot of code that will break in
the next 6 to 12 months.

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About