-
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
- disable bareword filehandles
- disable multidimensional array emulation (a Perl 4 trick)
- enable subroutine signatures
- change prototypes to use the
:prototypeattribute
In his announcement at The Perl Conference in the Cloud, Sawyer X (Perl Project Lead) said they'd like to have it within a year, but maybe sooner than that.
There's a core-p7 branch in the Perl repo on GitHub. Look for the known-issues.md for things that need attention.
Most likely it will. Perl 7 is Perl 5.32 with different defaults. If your code can run under v5.32, you are probably close to ready. Note that in the past several years, Perl 5 has removed features that were deprecated even when v5.0 was released in 1994. If you are using those, you 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. To specify the Perl 7 protocol, you specify the v7 protocol:
use v7;
To fall back to Perl 5.32, specify v5:
use v5;
You can get the preview version of the next major version
use v8;
There's no word on Perl 7 recognizing use v5.32 in Perl 5 code.
But, since Perl 7 is v5.32, you already know how to turn off defaults you don't like:
no strict;
{ no warnings; ... }
Don't rely on these as a crutch though. If you want to stick to Perl 5 behavior, you can still use Perl 5.
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).
We don't know the answer to this one yet. /usr/bin/perl is the system Perl. For at least a decade, I have been telling people not to use the system perl for user code. This is the perl that the system employs to handle system Perl programs. Each system will choose what they need, and it's likely they will stick with Perl 5 since everything using it will not have tested against or migrated to Perl 7 (because it doesn't exist yet). We are working with major packagers to figure out what works best for them. On my macOS box, that's v5.18 (and soon won't be there at all), but they are also taking it away.
Relying on the system means you let someone else make the decision for you, and it's a bigger problem than migrating to Perl 7, or even Perl at all. Let's say that your system provides an out-of-date perl, which is not uncommon. Then you update to v5.26. Now your regexes break because you have an unescaped left brace. Since you didn't control a key aspect of your user application, you didn't control the system's decision to break your code. People often find these issues after a system upgrade (planned or otherwise).
Having said that, my guess is that we'll have something close to the Python situation, where there's python, python2, and python3. So, we'd have perl (whatever the system needs, likely the same thing they are using now), perl5 (a symlink to perl), and perl7 (A different binary). That's just my guess based on how I've seen these things work elsewhere.
The Perl module paths are already set up for this too. We can put the version right in the @INC paths so two different versions can install modules into the same prefix (say, /usr/lib/perl) without conflicting with each other. Or they could simply use different prefixes.
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 get to decide how that happens.
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