-
Notifications
You must be signed in to change notification settings - Fork 560
Perl7 FAQ
Q: What about github.com/perl/perl5 is it named wrong now?
A: Yes it is. Github will let us rename the repo and redirects should work correctly.
Q: Is the idea that major numbers will be incremented every so often, like say, the linux kernel? or do you think it will be perl7 for a long time? just asking out of curiosity
A: Perl 8 will likely come in the next 3-5 years. We hope to have Cor in blead by then. No specific plans are in place beyond that.
Q:
A:
Perl 7 is Perl v5.32 with saner, more modern defaults. It's a transitional major version before we get to breaking changes.
There's a Perl 7 proposal in the wiki for the perl5 repo.
There was some thought to dropping the 5 from the version and using what we already think of as the major version. However, that would reinforce the idea that it's just a continuation of the Perl 5 line. And, 32 is a big number.
We could have done many things, but we had to choose one of them. Perl 7 is what we chose.
We're still talking about that here. We don't know for sure because we don't have Perl 7 yet. These are some of the things already on the list, although there's no guarantee on anything yet:
- enable strict by default
- enable warnings by default
- enable subroutine signatures
- disable Indirect Object Syntax
We'd like to be done in less than a year. Ideally sooner.
Right now we're early in planning. The details as we understand them can be found here.
The current plan is that Perl 7 will require a Protocol Declaration at the head of each file. We are working on a module that will convert CPAN modules during installation or source trees.
If your code can run under Perl 5.32, you should be able to run it under perl 7. Perl 5 has removed features that were deprecated even when v5.0 was released in 1994. If you are using those, you may need to fix that. Trying your code under v5.32 will find those problems for you.
There will be some compatibility modes—see Sawyer's announcement from July 3. The use VERSION is going to change behavior to specify major version "protocol" instead of minimum versions and feature bundles. This is a required declaration.
Perl 5 goes into long term maintenance. That can be as long as a decade or more. You'll still get important security and bug fixes, just for a little bit longer than usual.
The current Perl support policy guarantees support for the previous two maintenance releases. With a new maintenance release every year, this effectively means two years of support for a major release (such as v5.30 and v5.32).
Distros control what /usr/bin/perl is, not Perl development. We can provide a suggestion or guidance, especially in Configure. Even so, we feel this should be a late decision in the process and advice from distros will be sought even before we do this.
As the user, your decision is likely made for you. If you aren't going to install your own perl for your application, you're stuck on whatever the system provides. If you do install your own perl, you will get to decide how that happens.
We are endeavoring to make the scope of the bump to 7.0.0 as small as possible to make sure it does happen.
That's the gorilla-elephant hybrid in the room, isn't it? We did this once in 2000, didn't we? Perl 6 didn't turn out how we thought it would, but that's life sometimes.
If Perl 7 doesn't happen, we get Perl v5.34 and keep doing that.
But, it's very unlikely that we'll fail here. Perl 7 is v5.32. We already have all of the code, but it needs some clean-ups. This is more paper shuffling and administrative work than anything else. The Perl community already has the tools in place to test all of CPAN against any Perl release (I know, I get the emails about my modules being broken). Perl 7 is more about process adjustment than new code.
And, consider this: Perl finally moved to GitHub. It converted all of its reports in Request Tracker to GitHub issues. You can now interact with the perl5 repo on GitHub. That was a huge project, and it's the same people that made it happen.
Honestly, Perl 6 was announced without a plan. I was there (in the room) when we decided to invent it. Larry Wall announced the new direction that week with no plan, and called it "the community's rewrite of Perl". A long RFC process followed, which Mark Jason Dominus summarized for Perl.com.
This is different. Key people have been planning this for a year. They've carefully considered how big a bite they can take, and have a modest plan going into the next year. The code is already all there.
Some people realize that print and friends can be methods on the filehandle. Have you ever considered why there's no comma after the filehandle?
print STDOUT "Hello world!\n";
STDOUT->print( "Hello world!\n" );
So far, filehandles seem to be safe under no feature qw(indirect).
Perl 7 is v5.32 with different defaults. You won't see new features and you won't have any taken away from you if you're running on v5.32. If it's already in Perl, you can have it. If it isn't, probably not.
There are many things that people want, and I expect that Perl 8 will be the version that handles that. Perl 7 sets the stage for completely breaking with Perl 5 compatibility, but Perl 8 will be the major version that can actually do it.
There's the possibility of a new object system. Many people are interested in Ovid's Cor proposal. But, by "new", we really often mean syntactic sugar over what is already in the codebase. Since Perl 7 is compatible with v5.32, you aren't going to lose the way that Perl does it now.
Maybe. Let's see how much work that is. We'd all like to have this, but there's death and destruction in the wake of a big switch like that. Perl has all the features it needs to handle that, but we don't know how much of the community is ready for that.
But, this is not simply enabling some features. Changing the default behavior of encodings is likely to break many programs because the program itself needs to be ready for Unicode (there's a primer in an appendix to the latest Learning Perl. Tom Christiansen answered Why does modern Perl avoid UTF-8 by default?.
Perl 6 started as an ambitious effort to completely rewrite Perl. For various reasons, that didn't replace Perl and went off to live a separate life as the language now known as Raku. The number 7 was next in line.
One major version at a time! Let's figure out Perl 7 first.
Will Braswell does an amazing job of outlining the paths of various offshoots of Perl in his talk The Perl Family Tree.
Perl 6 happened, then struck out on its own as Raku.
The community has talked about a Perl 7 since at least 2013. One brave soul even made a toy project on GitHub, but that was never a serious attempt. It would have been based on NQP (Not Quite Perl), which would have made it compilable to MOAR, the engine that powers Raku.
Similarly, there was a thing called Perl 11, which was more an umbrella for a design philosophy behind several exploratory forks of Perl. These sort of projects let people try heterodox ideas, and that's fine. They just aren't perl.
- Getting Better, not Getting By, Sawyer's keynote at The Perl Conference in the Cloud
- Sawyer's announcement on p5p
- Sawyer's proposal for
use v7on p5p - Announcing Perl 7 on Perl.com
- Perl 7 tl;dr
- Preparing for Perl 7, from Perl School
- The Proposal for Perl 7