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
From:
David Mertens
Date:
July 2, 2020 16:42
Subject:
Re: Dual-life perl 5-or-7 code and prototypes - impossible?
Message ID:
CA+4ieYUDaHwLo8DtU7a9q1-CLEdDE-XEP=7s2DWb_RYz6r+Z6A@mail.gmail.com
Just a quick clarification about Sawyer's proposal. I thought he made this
clear in the talk, but you may have missed it.

In short, new features will be vetted in perl7 (and following) just as they
have in perl5, with feature guards. Any new behavior will be hidden behind
a feature guard and only available if you explicitly ask for it. The only
time a feature guard will be activated automatically is with a major
version update. So 7.2 would never automatically introduce feature
'lambda'. You would have to wait for v8 for that. (Except that renaming the
anonymous sub keyword to "lambda" is dumb and that'll never actually
happen. Cor is likely to be the big thing for v8, and that is not expected
to interfere with existing code anyway.)

We can expect a point release every year. How often would we see major
releases? Maybe every 3-5 years. They are supposed to enable features that
represent community consensus around best practices, and it'll take time
for those best practices to surface.

David

On Thu, Jul 2, 2020 at 11:42 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Wed, 1 Jul 2020 13:26:21 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
>
> > > On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans
> > > <leonerd@leonerd.org.uk> wrote:
> > >
> > > On Wed, 1 Jul 2020 07:31:42 -0500
> > > Todd Rinaldo <toddr@cpanel.net> 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:
>
>   https://metacpan.org/release/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:
>
>   https://metacpan.org/pod/Sub::Attribute::Prototype
>
> 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
>
> leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

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