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.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Announcing Perl 7
by haukex (Bishop) on Jun 24, 2020 at 21:30 UTC | |
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. | [reply] |
Re: Announcing Perl 7
by Your Mother (Archbishop) on Jun 24, 2020 at 19:29 UTC | |
Your code should work if it’s not a mess. So… like 14% of production Perl code will work. :P | [reply] |
by marto (Cardinal) on Jun 24, 2020 at 19:35 UTC | |
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. | [reply] |
by Your Mother (Archbishop) on Jun 24, 2020 at 20:03 UTC | |
I consider on a weekly basis retiring to forge original cosplay accessories and movie/anime/game replicas. :P | [reply] |
by LanX (Cardinal) on Jun 24, 2020 at 20:24 UTC | |
like no warnings Tho I don't know if this will work with :prototype() too.
editI really hope they won't introduce the experimental function signatures, since they lack named arguments.
Cheers Rolf | [reply] [d/l] [select] |
by haj (Curate) on Jun 24, 2020 at 20:50 UTC | |
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? | [reply] |
by LanX (Cardinal) on Jun 24, 2020 at 21:17 UTC | |
by Aaronrp (Scribe) on Jul 03, 2020 at 20:56 UTC | |
by LanX (Cardinal) on Jun 25, 2020 at 17:30 UTC | |
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
Cheers Rolf | [reply] [d/l] |
Re: Announcing Perl 7
by perlfan (Vicar) on Jun 24, 2020 at 21:24 UTC | |
| [reply] |
Re: Announcing Perl 7
by salva (Canon) on Jun 26, 2020 at 12:40 UTC | |
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... | [reply] |
by syphilis (Bishop) on Jun 26, 2020 at 13:32 UTC | |
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 | [reply] |
by LanX (Cardinal) on Jun 26, 2020 at 13:04 UTC | |
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
Cheers Rolf | [reply] [d/l] |
by salva (Canon) on Jun 26, 2020 at 14:58 UTC | |
"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? | [reply] |
by Your Mother (Archbishop) on Jun 26, 2020 at 16:13 UTC | |
by LanX (Cardinal) on Jun 26, 2020 at 15:09 UTC | |
by perlfan (Vicar) on Jun 27, 2020 at 07:16 UTC | |
Checkout the Pull Request Club covered in a lightning talk, Kivanc Yazan - State of Pull Request Club - Lightning Talks - Day 2. | [reply] |
Re: Announcing Perl 7
by k-mx (Scribe) on Jun 25, 2020 at 05:58 UTC | |
| [reply] |
Re: Announcing Perl 7
by bliako (Prior) on Jun 25, 2020 at 09:26 UTC | |
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 | [reply] |
by marto (Cardinal) on Jun 25, 2020 at 09:51 UTC | |
'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. | [reply] |
by bliako (Prior) on Jun 25, 2020 at 11:07 UTC | |
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.
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 | [reply] [d/l] |
by marto (Cardinal) on Jun 25, 2020 at 11:30 UTC | |
by bliako (Prior) on Jun 28, 2020 at 11:08 UTC | |
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 | [reply] |
Re: Announcing Perl 7
by syphilis (Bishop) on Jun 28, 2020 at 01:38 UTC | |
If you've got a spare hour or two, peruse Announcing Perl 7. Cheers, Rob | [reply] |
by bliako (Prior) on Jun 28, 2020 at 11:03 UTC | |
And here is the Vox Populi https://www.reddit.com/r/perl/comments/hf3jlx/announcing_perl_7/ | [reply] |
by LanX (Cardinal) on Jun 28, 2020 at 11:48 UTC | |
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.
Cheers Rolf PS: And for years now I was asking myself if there is any robust decision process in Perl's planning ... doesn't look like. | [reply] [d/l] |
by syphilis (Bishop) on Jun 28, 2020 at 12:41 UTC | |
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 | [reply] |
by LanX (Cardinal) on Jun 28, 2020 at 14:22 UTC | |
by salva (Canon) on Jun 28, 2020 at 12:17 UTC | |
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! | [reply] |
Re: Announcing Perl 7
by davido (Cardinal) on Jun 28, 2020 at 20:08 UTC | |
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. Dave | [reply] |
by hippo (Chancellor) on Jun 28, 2020 at 21:49 UTC | |
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. | [reply] |
by LanX (Cardinal) on Jun 28, 2020 at 22:04 UTC | |
this would be the best publicity Perl could get. BTW: am I wrong or doesn't git run on Perl?
Cheers Rolf | [reply] |
by davido (Cardinal) on Jun 28, 2020 at 22:56 UTC | |
Re: Announcing Perl 7 ( BOF - Perl7 Q&A soon)
by LanX (Cardinal) on Jun 25, 2020 at 12:18 UTC | |
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
updateBOFs are not live-streamed on YT, sorry.
Cheers Rolf | [reply] |
Re: Announcing Perl 7
by rhans (Initiate) on Jun 25, 2020 at 10:32 UTC | |
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. | [reply] |
by hippo (Chancellor) on Jun 25, 2020 at 11:24 UTC | |
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. | [reply] [d/l] [select] |
by choroba (Archbishop) on Jun 25, 2020 at 14:34 UTC | |
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.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply] [d/l] |
by dsheroh (Monsignor) on Jun 29, 2020 at 08:53 UTC | |
Re: Announcing Perl 7
by parv (Vicar) on Jun 25, 2020 at 12:04 UTC | |
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 | [reply] [d/l] [select] |
by hippo (Chancellor) on Jun 25, 2020 at 12:35 UTC | |
... 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?).
| [reply] [d/l] [select] |
by parv (Vicar) on Jun 25, 2020 at 13:26 UTC | |
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? | [reply] [d/l] [select] |
by choroba (Archbishop) on Jun 25, 2020 at 14:32 UTC | |
by marto (Cardinal) on Jun 25, 2020 at 12:07 UTC | |
"Not much to gain there." Unless they make it a James Bond themed release! | [reply] |
Re: Announcing Perl 7
by vkon (Curate) on Jun 28, 2020 at 14:33 UTC | |
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, | [reply] |
Re: Announcing Perl 7
by k-mx (Scribe) on Jun 25, 2020 at 03:34 UTC | |
P.S. What about "'" as package separator? | [reply] |
Re: Announcing Perl 7
by siberia-man (Pilgrim) on Jun 25, 2020 at 14:59 UTC | |
| [reply] |
by 1nickt (Abbot) on Jun 26, 2020 at 01:56 UTC | |
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:
Hope this helps!
The way forward always starts with a minimal test.
| [reply] |
by LanX (Cardinal) on Jun 26, 2020 at 02:32 UTC | |
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) Cheers Rolf | [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |