Announcing Perl 7

So in case you haven't been following the conference, Perl 7 has been announced. To quote brian_d_foy, a little tl/dr: 'Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year.', but you should probably just read the whole post, since, you know, details. Also Preparing for Perl 7.

Update: s/chromatic/brian_d_foy/. Thanks 1nickt.

[haukex]

Since it doesn't appear to have been linked to yet, Sawyer's keynote from today is at https://youtu.be/6wPMh-3qYJM, the "meat" of the Perl 7 stuff comes at roughly 48 minutes into the talk, though of course the entire talk leading up to that point is very relevant too.

[Your Mother]

Your code should work if it’s not a mess.

So… like 14% of production Perl code will work. :P

[marto]

Most code I look at these days is a mess, regardless of language. It can be depressing. I've decided to retire and forge artisan hammers (for which I can charge crazy prices, like some hipster barista), since people seem to love hitting themselves in the face while refusing to learn how to stop hitting themselves in the face, mostly due to laziness or habit. N.B. some actively enjoy moaning, so it's just a substitute for recreational drugs. Be warned, many of these hammer lovers will try and drag you down with them. Lest we forget, please Hammer Don't Hurt 'Em.

[Your Mother]

I consider on a weekly basis retiring to forge original cosplay accessories and movie/anime/game replicas. :P

[LanX]

As far as I understood is the idea that you will still be capable to switch off the new default pragmas.

like no warnings

Tho I don't know if this will work with :prototype() too.

edit

I really hope they won't introduce the experimental function signatures, since they lack named arguments.

[haj]

I really hope they won't introduce the experimental function signatures, since they lack named arguments.

That's strange. Why would you block a thing which is considered useful by quite a few Perlers only because some feature isn't available right now? Wouldn't it be better to suggest a parseable syntax how to write named arguments?

[LanX]

So the concept seems to be that a use compat::perl5; can be used to allow backwards compatibilty.

Details in this slack discussion https://perlfoundation.slack.com/archives/C014K7XQ5HA/p1593097091360400

 
LanX Heute um 16:58 Uhr
so let me summerize what I understood about planed backwards- compatibility for CPAN and Perl7

* if a module has "use 5.X" old features like sub (PROTOTYPE) { BLOCK }  will stay enabled
* if a CPAN -Modules has no "use 5.X" then it will be assumed by the CPAN-Installer to be 5ish, a Flag will be set  and the old features stay enabled
* it has to "use 7.X" to indicate that new features are enabled

not sure how the second point can be achieved without statically parsing the code, since use Statements are executed at compiletime

Did I get it right?

=== Update

One example of code without explicit Perl-Version is List::Util , (which is also CORE but nevertheless also on CPAN) (bearbeitet) 
16 Antworten

LanX  vor 2 Stunden
Please reply in thread ... (bearbeitet) 

autarch  vor 2 Stunden
No, absent any indication perl 7 will run code in "7 mode" (for lack of a better term), which includes strict & warnings by default

autarch  vor 2 Stunden
and other features

LanX  vor 2 Stunden
yeah but how do you plan to maintain code on CPAN which is supposed to run on both major versions?
5 has no "use oldPrototypes"
e.g, take a look at List::Util (bearbeitet) 

autarch  vor 2 Stunden
no idea, honestly

autarch  vor 2 Stunden
I'm just answering based on what I got from the presentation

LanX  vor 2 Stunden
I think hat's a crucial question and  I just asked in the BOF, and that's how I understood Todd.
But i prefer to ask again in a written form ...
regarding CORE modules, I think I saw Paul Evans yesterday mentioning that he doesn't know if he wants to maintain 2 versions of List::Util

Dakkar  vor 2 Stunden
a thing that Todd said: use compat::perl5 can be trivially written to work in perl5 (he has written it already); so, if a cpan maintainer has a module that won't "just work" in 7, they can add use compat::perl5; to it, add that module to the dependencies, and be done
:+1:
1


Dakkar  vor 2 Stunden
https://gist.github.com/toddr/0c280d3a4f5951776cd0d1e6d49dba11

LanX  vor 2 Stunden
true  ... but he also said that the installer would introduce it automatically for other modules (like unmaintained ones) ... right?

Dakkar  vor 2 Stunden
yes, which wouldn't even be that hard (add that line after every package declaration, or at the top of the file, if the META.yaml doesn't say the distribution requires perl => '>= 7.0'
:+1:
1


Dakkar  vor 2 Stunden
(disclaimer: I'm not a core dev, and I'm handwaving a lot)

LanX  vor 2 Stunden
OK ... that sounds reasonable

Dakkar  vor 2 Stunden
I'm sure there's tons of weird cases where it won't Just Work™, but this covers a lot of ground

LanX  vor 2 Stunden
Yeah ... sorry for insisting ... but before talking about more feature requests we have to get this right
:+1:
1

[salva]

I hope people doing that would take into consideration that most of the modules available from CPAN are not being maintained anymore (or just barely) and that they just keep working because of Perl excellent backward compatibility (so far).

In my particular case, I have not been using Perl for anything but very small scripts and one-liners for the last two years. I am still maintaining (what I consider) my most important modules, fixing bugs when they are reported, etc. But the day they tell me that some Perl release has broken all (or most) of them, I would probably say, so long...

[syphilis]

But the day they tell me that some Perl release has broken all (or most) of them, I would probably say, so long...

Please don't do that.
IMO, there are only 2 or 3 valid excuses for abandoning modules that one has uploaded to CPAN:
1) death
2) dementia

Otherwise, officially request that someone else start maintaining that module.
And if there are no takers, then we have:
3) no takers

Cheers,
Rob

[LanX]

that's the plan Re^2: Announcing Perl 7

edit

"old" CPAN modules will be assumed to be compatible to Perl5.

"new" modules will have a metatag "Perl 7" (or maybe a use 7.xx.xx ?)

So whatever the final solution, old code from CPAN is supposed to still run on P7

[salva]

"new" modules will have a metatag "Perl 7"

IMO, that just over-complicates everything.

What would happen with modules that are not packed? That's quite common for private applications, having all the modules (*.pm files) placed in a tree of directories, probably under some VCS. Could I write new modules for that application in Perl 7 while keeping the old ones untouched?

Supporting different Perl versions has been a solved problem for a long time: you just add "use 7" at the beginning of every perl script or module and that activates the specific semantics for that version. It is reliable and minimal.

For those that believe that adding "use 7" is too much boilerplate, think what would happen when the slightly incompatible 7.01 comes out?

[perlfan]

>most of the modules available from CPAN are not being maintained anymore (or just barely)

Checkout the Pull Request Club covered in a lightning talk, Kivanc Yazan - State of Pull Request Club - Lightning Talks - Day 2.

[perlfan]

This is good news. Congratulations to all involved. Leap frogging over Perl 6 was the logical thing to do, especially after it changed the name (another move years late).

[k-mx]

Nice article http://blogs.perl.org/users/leon_timmermans/2020/06/not-quite-getting-better-yet.html. How to not break system code on Perl? What will happen with one liners?

[bliako]

I read the link http://blogs.perl.org/users/leon_timmermans/2020/06/not-quite-getting-better-yet.html posted by k-mx and then this comment under it:

And if there were a binary /usr/bin/perl7 which was like /usr/bin/perl -M7, would that be OK?

"Nature abhors a vacuum". I should add: and Nature works its way without asking anyone or caring about anyone's plans or feelings. It's also true that a lot of the side-effects of Nature's ways can not be anticipated even by today's science: it's a chaotic or too complex a system sometimes. So, I hope those who are in charge of this know their limitations *in predicting* the side-effects.

Fair enough, the cited comment's scenario is closer to aliasing than having multiple, versioned (system-wide) binaries. But who can say that sooner or later the alias does not become a distinct binary because that's simply convenient. And who would say that, as people subconsciously love stereotypes, the alias becomes versioned binary in people's minds and soon the label sticks. And it affects decisions in board-rooms.

Here is my suggestion for an experiment: when there is a working prototype for these changes, clone CPAN and test all modules with it. Note the % of failures, that's one metric. Then pick *at random* a relatively small number of modules and try to "fix" them. Categorise each fix in "easy", "hard", "impossible" etc. These numbers should then be multiplied by 10x to see the effect on real code "out there".

Just a few thoughts from a non-professional Perl user who admits I would prefer to see Perl first conquering Bioinformatics (it can surely be done by just more *man-power on existing efforts), trying to act as a scripting glue for R - oh boy who wouldn't like to have the power of R from Perl rather than ... R - and AI algorithms in general. It requires user-friendly, easier way to interface with existing binary (super-fast, already tested) libraries, by XS being majorly upgraded for ease-of-use and Inline::* work perfectly (see my futile attempt to interface with opencv - which is state-of-the-art - because of ... eehmmm ... internal variables name conflicts: Inline::CPP + OpenCV = problems). I could also add making PDL more accessible, why can't its use be transparent in Perl??? Now, for me, these are projects worth taking on and let signatures wait a bit longer.

bw, bliako

[marto]

'Here is my suggestion for an experiment: when there is a working prototype for these changes, clone CPAN and test all modules with it.'

There's no need to 'clone CPAN', smoketesters/cpantesters already provides the required functionality, anyone can smoketest cpan for any version of perl, for any OS, automatically reporting failures.

'These numbers should then be multiplied by 10x to see the effect on real code "out there".'

The number you'd end up with makes no sense at all in terms of what you seem to believe it would illustrate.

'I would prefer to see Perl first conquering Bioinformatics'

Be sure to post here when you create a group/movement working towards this goal.

'who wouldn't like to have the power of R from Perl rather than ... R'

Isn't that what Statistics::R claims to do? "Statistics::R is a module to controls the R interprete".

'I could also add making PDL more accessible, why can't its use be transparent in Perl???'

See above.

[bliako]

Be sure to post here when you create a group/movement working towards this goal.

There is already at least one group doing that and quite well but is not catching up IMO with other alternatives, e.g. python. I am talking about *officially* directing *funding* and man-power to this or similar projects which may have a + net-effect on establishing Perl, again, in Research, Universities, AI. (I am not affiliated with that or any other project, neither I know any of those working on them). The distinction between officially spearheading a project/direction and individually or in groups creating CPAN modules must be clear even to a not-so-well-meaning observer.

My suggested experiment is a means to assess how much potential breaks and how much effort to fix them. I said "clone" because some modules will have to be modified in order to be "fixed" for the new version. 10x is an ad-hoc multiplier to extrapolate the findings from code which has been peer-reviewed, tested and used under many circumstances by thousands (CPAN modules), to code which is private/corporate and lives in dungeons, rarely seen by more than 50 people.

Statistics::R is just a way to send and receive to an R process. It leaves a lot to be desired, e.g. getting back data structures from R, re: the omni-present data.frame. This is what I am talking about and not about reading the stdout of an R session which is trivial.

# see https://www.dummies.com/programming/r/how-to-create-a-data-frame
+-from-scratch-in-r/
use Statistics::R;
my $R = Statistics::R->new();
my $out = $R->run(<<EOR);
employee <- c('John Doe','Peter Gynn','Jolie Hope')
salary <- c(21000, 23400, 26800)
startdate <- as.Date(c('2010-11-1','2008-3-25','2007-3-14'))
employ.data <- data.frame(employee, salary, startdate)
str(employ.data)
EOR
my $frame = $R->get('employ.data');
use Data::Dumper;
print Dumper($frame);
$VAR1 = [
          'employee',
          'salary',
          'startdate',
          '1',
          'John',
          'Doe',
          '21000',
          '2010-11-01',
          '2',
          'Peter',
          'Gynn',
          '23400',
          '2008-03-25',
          '3',
          'Jolie',
          'Hope',
          '26800',
          '2007-03-14'
        ];

Typical scenario: I want to plot data just scraped with Perl using R's excellent ggplot which works mostly with data.frame. Or, I want to get statistics metrics of some other data from Perl and R provides that easily and reliably but it requires to convert R's results back to a Perl object. Which is not trivial but also not impossible. Again, I should think official support is very important for these projects. I may be naive here but the example I cite with opencv could be resolved if perl guts could be altered to scope better and keep its internals airthight. For comparison, python pandas have converters from/to R structures, e.g. data.frame.

bw, bliako

[bliako]

Regarding the "experiment" I mentioned above, here is a similar idea from the discussion at p5p cited by syphilis, posted afterwards: https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257591.html (comment by Karen Etheridge on June 26, 2020 18:04 - minor 1' edit tos supplement this info):

One thing that could help (and I have asked for this in the past;
unfortunately I have lacked the tuits to do it myself) is to compile
variants of perl with these pragmas forcibly turned on, and smoke all of
cpan with it to see the outcome.  As a cpan author and janitor, I would
certainly appreciate being able to see which distributions within my
control are affected by certain pragma or feature options, so that I can
proactively move to make appropriate fixes.  There may also be some
surprising findings from this exercise that would help inform us which
pragmas and features should be enabled or not enabled.  Core and dual-life
modules would also no doubt be affected, and they MUST all be fixed for
whatever default feature set is decided upon.

I think this is important. The logical next step, as I proposed, should be "measuring" the difficulty of the fixes by randomly selecting and fixing some modules and then extrapolating that figure for all Perl code "out there" using some rules of thumb not least of which: how exposed is the code to peer reviews (e.g. public CPAN module vs private/corporate) - but how to do this is a minor detail. Saying "X% of randomly selected modules were fixed 'easily' and Y% harder" is the important bit (so please no nit-picking).

bw, bliako

[syphilis]

I'm not sure if this has already been mentioned in this thread (as I haven't studied it closely) but this announcement has certainly livened up the p5p mailing list - and it's not all positive.
If you've got a spare hour or two, peruse Announcing Perl 7.

Cheers,
Rob

[bliako]

And here is the Vox Populi https://www.reddit.com/r/perl/comments/hf3jlx/announcing_perl_7/

[LanX]

Sigh ... When navigating a mailinglist post by post I start to really appreciate PM's subthread view.

But thanks anyway! ++

It seems like the

use v7 yes or no?

issue is unresolved yet.

My gut feeling is that we will stick with this v7 mechanism and delay fancier approaches to Perl8.

PS: And for years now I was asking myself if there is any robust decision process in Perl's planning ... doesn't look like.

[syphilis]

PS: And for years now I was asking myself if there is any robust decision process in Perl's planning ... doesn't look like.

I feel sympathy for SawyerX who, I'm sure, is merely trying to do the best thing for perl.
And if you're the "leader" of the organization, then it should be ok for you to make an executive decision without going through the long and dreary process of first consulting with everyone.
But, as soon as he does that, people start disagreeing with him and questioning his lack of pre-consultation.
I guess that, from my POV, an astute "leader" would consult first ... and then make the executive decision.

I find myself also wondering whether Larry's decision to rename perl6 to raku was a case of "doing the right thing by the perl5 community" ... or was it a case of providing the perl5 community with enough rope ?
I'm not saying that Larry is evil ... but I wouldn't be surprised if he's very shrewd.

Anyway, the arguments about what should be done to advance from perl5 to perl7 and beyond are somewhat over my head.
My aim will be to just deal with whatever gets thrown at me in such a way that my modules on CPAN work with all perl versions from 5.8 onwards.

Cheers,
Rob

[salva]

Sigh ... When navigating a mailinglist post by post I start to really appreciate PM's subthread view.

For perl.org lists there is a NNTP gateway available (see https://lists.perl.org/list/perl5-porters.html). I use Thunderbird to read it and find it far more friendly than the web interface, and it also allows me to participate in the conversations!

[davido]

I'm so glad this is happening.

I'm particularly interested in seeing this work its way through to Linux distribution vendors. Ubuntu 20.04 comes with Perl 5.30. I'd love to see a future release using Perl 7, or 8. I'd love to see this happen in Redhat/Centos, etc, as well. Those of use who use Perl a lot are comfortable installing our own version, but making a current version be the one the rest of the world sees, and having that version have sane defaults, that's going to be a step forward.

The other thing I've really appreciated is seeing Perl development to be working through Github instead of RT. In 2020, if you want your project to be accessible to potential contributors, and to be used, it should probably be on Github.

So good work, to those who have made the decision to jump versions, and who got Perl development moved to a modern source code repository.

[hippo]

The other thing I've really appreciated is seeing Perl development to be working through Github instead of RT. In 2020, if you want your project to be accessible to potential contributors, and to be used, it should probably be on Github.

It should probably be on somewhere like Github. RT is great but obviously doesn't offer pull requests which is the key difference (AFAICS). But in 2020 I wouldn't recommend Github either as it is owned by you-know-who and they could subvert or kill it at a moment's notice. There are enough other, independent places to host your project. With something as big as Perl itself self-hosting is always an option too.

[LanX]

> and they could subvert or kill it at a moment's notice.

this would be the best publicity Perl could get.

BTW: am I wrong or doesn't git run on Perl?

[LanX]

Just discovered...

There is a BOF - Perl7 Q&A at the next full hour (3pm Central European Summer Time)

If you're registered you can also ask questions via zoom... ;-)

Otherwise try to follow on YouTube

update

BOFs are not live-streamed on YT, sorry.

[parv]

I will welcome the version after 7.0.0, for .0.0 version would be very much the same as 5.32. Not much to gain there.

I especially like the plan that experimental features would be temporary, turning into the core of the language or be removed. I just hope Perl 7 does not create its own backward compatibility baggage anew to tow (until Perl 8?).

Another thing I like about proposed Perl 7 is that it would also remove the need to specify a perl version in order to use non-experimental, permanent features that that particular version brings. hippo corrected me later For example, need to add use v5.10; to use //= with perl 5.10.

[hippo]

... it would also remove the need to specify a perl version in order to use non-experimental, permanent features that that particular version brings. For example, need to add use v5.10; to use //= with perl 5.10.

Perhaps I've misunderstood you but I don't think that would be a change. I can quite happily use defined-or-equals without such a declaration in 5.10 (admittedly 5.10.1 which is the nearest version to which I have access - is it different for 5.10.0?).

$ perl -v | head -3

This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

$ perl -e '$z //= 20; print "$z\n";'
20
$

[parv]

Thanks much, hippo, for correcting me. I might have mixed my memory of use 'v5.10' so that program would not compile with perl 5.8 when using "//=".

Would a better example be of say where in perl 5.32 still need to enable it via feature or v5.10?

[marto]

"Not much to gain there." Unless they make it a James Bond themed release!

[rhans]

Im skeptical to this announcement. Is this announcement a carefull attempt to test the waters before going full steam ahead with Perl 7? Exactly how much support does this have from the community? My first impression is; I dont like this.

My work with Perl primarily consists of maintaining and extending a major object-oriented codebase. The codebase is only a year old, written from scratch by me, for my current employer. All code follows Perl 5 best practices. I use a lot of Moose, so warnings and strict is mostly on by default from Moose. While these new defaults would likely help me out, I would rather prefer to explicitly type out my "use" statements on top of each file.

I can also add that I dont take any issue with the possibility of having to rewrite portions of my code over time, to stay compatible with perl 7. Rewriting my own code for improvement is fine.

What I dont like is the potential for breaking changes towards CPAN modules, specifically mature modules that are "done", and may not be actively maintained, but perfectly safe to use.

I also dont like the potential for breaking linux/distro tooling, and probably being force to run multiple versions of Perl.

[hippo]

I am somewhat skeptical too. 10 or 15 years ago this would have been great news and would have neatly side-stepped most of the negative attitudes to Perl arising from the schism. However, now that so much water has flown under the bridge and the naming situation was finally resolved last year the potential marketing gain from this is relatively minor.

So for me it all rests on the backwards compatibility. Haven't we all seen how just a few minor incompatible tweaks in recent releases have caused significant numbers of problems? I'm think here mostly of the removal of '.' from @INC and the inability to write for my $foo qw/bar baz/ {...} which broke lots of existing and important modules, many of which remain unpatched.

What I would like to see is a minimally-transparent way to have perl7 behave exactly like perl5 with no caveats. The only way I can see to do this is with an environment variable. It could be set once per server (and overridden per user/app/whatever) and then the job is done. If that can happen (and be thoroughly tested) then I'll be prepared to throw my inconsiderable weight behind it.

The announcement by contrast only mentions a pragma (compat::perl5) which might be usable via $PERL5OPT (or $PERL7OPT more likely). So if we can set PERL7OPT=-mcompat::perl5 then that should be manageable. It's still going to require extensive testing, of course.

In the meantime, I will continue to forge ahead with perl5.

[choroba]

> it all rests on the backwards compatibility.

Watch the announcement. Sawyer talks about people who need that and how Perl treated them in the past, and why it's time to change it.

[vkon]

the idea of renaming perl5 to perl7 was on the air long ago - http://blogs.perl.org/users/andrew_shitov/2013/02/more-on-perl-7.html

perl6 problem was recognized back then, and the consensus was "of course not!"

I think renaming is absolutely needed long ago, today is better than never,
but implementation details killing Perl even more.

[k-mx]

A fly in the ointment: less moves for code golf :)
P.S. What about "'" as package separator?

[siberia-man]

Just five cents of offtopic. Couple dozens years ago I've seen a message that the best or latest or somehow significant Perl version would be 6.28 (like 2*PI). To be honest, I don't remember the source of this note. Does this news correlate with that old note somehow?

[1nickt]

No, it doesn't. Perl "6" is dead, now a new language called Raku. The major version jump to 7 is partly to get past that confusion.

To quote the announcement on perl.com:

Why 7 and not 6?

There are two parts to this answer. First, “Perl 6” was already taken by what is now known as Raku. A long time ago, we thought that a very ambitious rewrite effort would replace v5.8. In short, that’s not what happened and the language has gone on to live a life of its own.

So, 7 was the next available number. That’s it. It’s just the next cardinal number in line.

Hope this helps!

[LanX]

I think the intended pun was that you can only approximate 2 pi but never reach it.

IIRC it's from the time the project was revived with a haskell implementation.

In this sense, yeah we are "over" Perl 6 now. ;)

Edit: Yep, see Pugs (programming)