perl.perl5.porters https://www.nntp.perl.org/group/perl.perl5.porters/ ... Copyright 1998-2022 perl.org Tue, 06 Dec 2022 14:48:26 +0000 ask@perl.org Re: Corinna (OOP) "Quickstart" Tutorial by Oodler 577 via perl5-porters * Neil Bowers &lt;neilb@neilb.org&gt; [2022-12-05 13:54:22 +0000]:<br/><br/>&gt; Ron Savage asked me to forward his suggestion:<br/>&gt; <br/>&gt; &gt; There is a superb new type of wiki called a TiddlyWiki which is perfect<br/>&gt; &gt; for this job. I use 15 or 16 or them, for different projects.<br/>&gt; &gt;<br/>&gt; &gt; See tiddlywiki.com. The homepage is itself a TiddlyWiki.<br/>&gt; &gt;<br/>&gt; &gt; There are many advantages over and above the old-fashioned type of wiki.<br/><br/>It&#39;d be need to see a &quot;rosetta code&quot; kind of thing, but for Perl Object Oriented<br/>Programming frameworks and methods. I think this would be great for adoption<br/>to show how to do X in: Moose, Corinna, I&lt;old school&gt; POOP, etc.<br/><br/>Implementing complex data structures and things might be outlier use cases, but<br/>they certainly would test design assumptions. I am particularly interested in seeing<br/>how Corinna mixes with existing or idiomatic Perl.<br/><br/>Cheers,<br/>Brett<br/><br/>-- <br/>oodler@cpan.org<br/>oodler577@sdf-eu.org<br/>SDF-EU Public Access UNIX System - http://sdfeu.org<br/>irc.perl.org #openmp #pdl #native<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265204.html Mon, 05 Dec 2022 20:26:23 +0000 Re: DAVEM TPF Grant#3 Nov 2022 report by wolfsage On Mon, Dec 5, 2022 at 4:36 AM Dave Mitchell &lt;davem@iabyn.com&gt; wrote:<br/>&gt;<br/>&gt; This is my monthly report on work done during November covered by my TPF<br/>&gt; perl core maintenance grant.<br/>&gt;<br/><br/>+1 from me. Thanks Dave!<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265203.html Mon, 05 Dec 2022 16:22:48 +0000 Re: PSC #089: 2022-12-02 by demerphq On Mon, 5 Dec 2022 at 15:22, Paul &quot;LeoNerd&quot; Evans<br/>&lt;leonerd@leonerd.org.uk&gt; wrote:<br/>&gt;<br/>&gt; On Mon, 5 Dec 2022 15:03:49 +0100<br/>&gt; demerphq &lt;demerphq@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; &gt; Part of the english names ticket is pretty easy, and IMO totally<br/>&gt; &gt; doable by a relatively new contributor. Part of it is probably not.<br/>&gt;<br/>&gt; I had an initial dip into it and it looked far from trivial. I thought<br/>&gt; I had a good guess on how gv.c makes the current ones work but it&#39;s<br/>&gt; really wrong, and not at all obvious how to do more of them :/<br/><br/>Hrm. That doesn&#39;t reflect my experience with adding new ones (I have<br/>added a few over the years). I&#39;ll take a closer look.<br/><br/>&gt; &gt; I don&#39;t know enough about qt to comment.<br/>&gt;<br/>&gt; To implement qt, first you need to understand how current qq() quoting<br/>&gt; and interpolation works. I&#39;m not sure I do. I could maaaaybe find it<br/>&gt; given enough poking around in toke.c.<br/>&gt;<br/>&gt; To any brave explorers who wish to wade into these waters, I can only<br/>&gt; offer the advice: Good luck, have fun, don&#39;t die.<br/><br/>Heh. Given my own limited negative experiences of trying to add qr//S<br/>which should be easy given most of it already exists, I am sympathetic<br/>to your advice.<br/><br/>cheers,<br/>yves<br/><br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265202.html Mon, 05 Dec 2022 15:11:53 +0000 Re: PSC #089: 2022-12-02 by Paul "LeoNerd" Evans On Mon, 5 Dec 2022 15:03:49 +0100<br/>demerphq &lt;demerphq@gmail.com&gt; wrote:<br/><br/>&gt; Part of the english names ticket is pretty easy, and IMO totally<br/>&gt; doable by a relatively new contributor. Part of it is probably not.<br/><br/>I had an initial dip into it and it looked far from trivial. I thought<br/>I had a good guess on how gv.c makes the current ones work but it&#39;s<br/>really wrong, and not at all obvious how to do more of them :/<br/><br/>&gt; I don&#39;t know enough about qt to comment.<br/><br/>To implement qt, first you need to understand how current qq() quoting<br/>and interpolation works. I&#39;m not sure I do. I could maaaaybe find it<br/>given enough poking around in toke.c.<br/><br/>To any brave explorers who wish to wade into these waters, I can only<br/>offer the advice: Good luck, have fun, don&#39;t die.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265201.html Mon, 05 Dec 2022 14:22:57 +0000 Re: PSC #089: 2022-12-02 by demerphq On Fri, 2 Dec 2022 at 17:59, Paul &quot;LeoNerd&quot; Evans <br/>&lt;leonerd@leonerd.org.uk&gt; wrote: <br/>&gt; <br/>&gt; On Fri, 2 Dec 2022 11:55:45 -0500 <br/>&gt; Felipe Gasper &lt;felipe@felipegasper.com&gt; wrote: <br/>&gt; <br/>&gt; &gt; &gt; These are items that seem generally popular as things people would <br/>&gt; &gt; &gt; like to use, but with nobody working on implementing, they are <br/>&gt; &gt; &gt; likely to fall off the tracker at some point in the near future. <br/>&gt; &gt; &gt; Volunteers welcome? &eth;&#159;&#153;&#130; <br/>&gt; &gt; <br/>&gt; &gt; Are there write-ups that detail the actual help needed with these? <br/>&gt; <br/>&gt; &quot;Design work is all done. Take a branch of bleadperl, implement it, <br/>&gt; submit a PR&quot;. <br/>&gt; <br/>&gt; Basically ;) <br/> <br/>FWIW, <br/> <br/>Part of the english names ticket is pretty easy, and IMO totally <br/>doable by a relatively new contributor. Part of it is probably not. <br/> <br/>I&#39;d expect that the optional chaining and removing support for &#39; as a <br/>separator are not trivial and would require a fairly brave new <br/>contributor or a scarred and cynical old timer. <br/> <br/>I don&#39;t know enough about qt to comment. <br/> <br/>Yves <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265200.html Mon, 05 Dec 2022 14:04:07 +0000 Re: Corinna (OOP) "Quickstart" Tutorial by demerphq On Fri, 2 Dec 2022 at 11:02, Ovid &lt;curtis.poe@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; Hi all, <br/>&gt; <br/>&gt; Several times I&#39;ve seen variations of &quot;I&#39;ve not really followed the Corinna project, but ...&quot;. Part of the problem is how long the discussions have been ongoing and how the information about the different bits are scattered across various sections of the full RFC. I previously wanted to write a &quot;quickstart&quot; guide, but we were in too much flux. Now, I have one: https://gist.github.com/Ovid/e0381355da7136654e92418a43c97611 <br/>&gt; <br/>&gt; It&#39;s in a gist for now because it&#39;s a work in progress and will need refinement later (and I&#39;ve realized that I can&#39;t easily create perldoc -f $keyword sections in perlfunc due to the size of the project. Suggestions on how to organize the POD documents for the new system are welcome. At minimum, we&#39;ll need separate sections for: <br/>&gt; <br/>&gt; The class keyword <br/>&gt; The role keyword <br/>&gt; The field keyword <br/>&gt; The method keyword <br/>&gt; A tutorial <br/>&gt; <br/>&gt; Suggestions welcome. <br/>&gt; <br/>&gt; The guide is not complete, but gives a brief introduction to the four new keywords, class, role, field, and method. It takes you from &quot;nothing&quot; to building a simple LRU cache which consumes a role to provide JSON serialization (the role is simplistic, to be honest). <br/> <br/>I would really like to see a non-trivial data structure implemented in <br/>Corinna. Eg, something like a 2-3 tree, or a treap. Something that <br/>demonstrate the trickier aspects of creating an object based data <br/>structure using it. <br/> <br/>yves <br/> <br/> <br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265199.html Mon, 05 Dec 2022 13:57:59 +0000 Re: Corinna (OOP) "Quickstart" Tutorial by Neil Bowers Ron Savage asked me to forward his suggestion:<br/><br/>&gt; There is a superb new type of wiki called a TiddlyWiki which is perfect<br/>&gt; for this job. I use 15 or 16 or them, for different projects.<br/>&gt;<br/>&gt; See tiddlywiki.com. The homepage is itself a TiddlyWiki.<br/>&gt;<br/>&gt; There are many advantages over and above the old-fashioned type of wiki.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265198.html Mon, 05 Dec 2022 13:54:39 +0000 DAVEM TPF Grant#3 Nov 2022 report by Dave Mitchell This is my monthly report on work done during November covered by my TPF<br/>perl core maintenance grant.<br/><br/>This month I restarted work in earnest on making the stack reference<br/>counted. I have reached the point where:<br/><br/>Around 250 PP functions have been wrapped - this means that the original<br/>functions will continue to work in the new regime, albeit more slowly.<br/>Each wrapped function can later be individually worked on to remove the<br/>wrapper and regain performance.<br/><br/>The remaining 50 or so PP functions were either so trivial that they<br/>didn&#39;t need wrapping, or (for most of them) so complex that they needed to<br/>be hand-crafted to work on both a RC and non-RC stack environment. The<br/>ones needing work included most of the pp_enterfoo() and pp_leavefoo()<br/>functions, along with things like map, grep, sort, goto etc. Fixing these<br/>complex functions is what has mostly been consuming my time.<br/><br/>At the moment these functions don&#39;t actually do reference counting: all<br/>the new inline functions which push and pop items off the stack etc<br/>currently skip the RC++ or RC-- bit. But I am nearly at the stage where I<br/>will actually turn on ref-counting, at which point I will have the fun of<br/>fixing all the things I blindly changed which it turns out were wrong.<br/><br/>The Programmer&#39;s Credo:<br/><br/> We choose to do these things not because they are easy,<br/> but because we thought they would be easy.<br/><br/>SUMMARY:<br/> 0:36 diagnose smoke failures in dist/Tie-File/t/29a_upcopy.t<br/> 1:00 fix stderr build noise<br/> 33:53 make stack reference counted<br/> 12:36 process p5p mailbox<br/> 1:20 review OPpEMPTYAVHV_IS_HV<br/> 0:10 review PR #20526<br/> ------<br/> 49:35 TOTAL (HH::MM)<br/><br/><br/>-- <br/>&quot;You may not work around any technical limitations in the software&quot;<br/> -- Windows Vista license<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265197.html Mon, 05 Dec 2022 09:36:53 +0000 Re: Compiletime-only lexical hints by demerphq On Sat, 3 Dec 2022 at 14:15, Paul &quot;LeoNerd&quot; Evans <br/>&lt;leonerd@leonerd.org.uk&gt; wrote: <br/>&gt; <br/>&gt; On Sat, 3 Dec 2022 13:43:15 +0100 <br/>&gt; demerphq &lt;demerphq@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; &gt; Isn&#39;t the problem that there is no clear compiletime/runtime <br/>&gt; &gt; distinction in perl? Code could be evaled in any block that needs to <br/>&gt; &gt; know the hints in effect. Isnt that the whole point? <br/>&gt; &gt; <br/>&gt; &gt; Eg, using the regex debugger is managed by hints. You expect this to <br/>&gt; &gt; trigger the regex debugger: <br/>&gt; &gt; <br/>&gt; &gt; my $pattern; <br/>&gt; &gt; my $qr= do { <br/>&gt; &gt; use re &#39;debug&#39;; <br/>&gt; &gt; eval &#39;qr/$pattern/&#39;; <br/>&gt; &gt; }; <br/>&gt; &gt; <br/>&gt; &gt; So if the hints arent frozen at opcode production time, if the opcodes <br/>&gt; &gt; produce more opcodes they will have the wrong hints.. <br/>&gt; <br/>&gt; Right; that&#39;s an example of a hint that definitely should be frozen for <br/>&gt; runtime so that eval() can re&Atilde;&para;pen it again later on. That&#39;s definitely <br/>&gt; fine. <br/>&gt; <br/>&gt; Many of my modules (ab)use the hints hash to store data between parts <br/>&gt; of their own compilation, having no further need for it at runtime. <br/>&gt; It&#39;s those ones I was thinking of. <br/> <br/>Can you give us an example? I am really struggling here to understand <br/>how a hint could be useful to compilation of a given block of code, <br/>but irrelevant to the compilation of code in an eval string in that <br/>scope. I can understand that /some/ code in an eval STRING might not <br/>be affected by a given hint, but surely anyone could put code in the <br/>eval string that *would* be affected by it? <br/> <br/>In theory I have no objection to what your propose, but i have a <br/>feeling it will be the source of long term bugs, as people encounter <br/>situations with eval STRING that don&#39;t work as expected. It would be a <br/>lot easier to understand why that wouldnt be a problem if you gave a <br/>solid example. <br/> <br/>cheers, <br/>Yves <br/> <br/> <br/> <br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265196.html Mon, 05 Dec 2022 09:15:02 +0000 Re: Deprecation of smartmatch by Paul "LeoNerd" Evans On Sun, 4 Dec 2022 15:08:45 +0100 <br/>Martijn Lievaart &lt;m@rtij.nl&gt; wrote: <br/> <br/>&gt; A thought occured to me of a possible problem here. Consider: <br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; $its_in = $needle in:=~ qr/haystack/; <br/>&gt; <br/>&gt; v.s. <br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; $its_in = $needle in:&lt; @haystack; <br/>&gt; <br/>&gt; Wouldn&#39;t the first to be the RHS of the op, and the second the LHS? <br/>&gt; Wouldn&#39;t this create a problem? Or do I simply misunderstand? <br/> <br/>I&#39;m not sure I see the problem. <br/> <br/>Actually for several reasons. Firstly, `in` doesn&#39;t permit arbitrary <br/>operators. Only `eq`, `==`, or anything custom registered with <br/>XS::Parse::Infix that says it is an equality operator (thus permitting <br/>`equ` and `===`). It would not permit `&lt;` or even `=~`. <br/> <br/>Secondly I don&#39;t at all follow what you mean about &quot;be the RHS of the <br/>op&quot; here. Can you explain it some more? <br/> <br/>-- <br/>Paul &quot;LeoNerd&quot; Evans <br/> <br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS <br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265195.html Sun, 04 Dec 2022 22:54:17 +0000 Re: Compiletime-only lexical hints by Oodler 577 via perl5-porters Neat, something new to explore for me :-) <br/> <br/>While you&#39;re asking, it seems &#39;#&#39; (as in a comment) or &#39;=&#39; <br/>(as in POD =head1) would be just as, if not more, familiar <br/>than &#39;!&#39;. Even &#39;^&#39; (as in a &#39;not&#39; character class in a regexp <br/>could work. There might be others but I can&#39;t think of any <br/>atm. <br/> <br/>Cheers, <br/>Brett <br/> <br/>* Paul &quot;LeoNerd&quot; Evans &lt;leonerd@leonerd.org.uk&gt; [2022-12-03 13:15:39 +0000]: <br/> <br/>&gt; On Sat, 3 Dec 2022 13:43:15 +0100 <br/>&gt; demerphq &lt;demerphq@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; &gt; Isn&#39;t the problem that there is no clear compiletime/runtime <br/>&gt; &gt; distinction in perl? Code could be evaled in any block that needs to <br/>&gt; &gt; know the hints in effect. Isnt that the whole point? <br/>&gt; &gt; <br/>&gt; &gt; Eg, using the regex debugger is managed by hints. You expect this to <br/>&gt; &gt; trigger the regex debugger: <br/>&gt; &gt; <br/>&gt; &gt; my $pattern; <br/>&gt; &gt; my $qr= do { <br/>&gt; &gt; use re &#39;debug&#39;; <br/>&gt; &gt; eval &#39;qr/$pattern/&#39;; <br/>&gt; &gt; }; <br/>&gt; &gt; <br/>&gt; &gt; So if the hints arent frozen at opcode production time, if the opcodes <br/>&gt; &gt; produce more opcodes they will have the wrong hints.. <br/>&gt; <br/>&gt; Right; that&#39;s an example of a hint that definitely should be frozen for <br/>&gt; runtime so that eval() can re&ouml;pen it again later on. That&#39;s definitely <br/>&gt; fine. <br/>&gt; <br/>&gt; Many of my modules (ab)use the hints hash to store data between parts <br/>&gt; of their own compilation, having no further need for it at runtime. <br/>&gt; It&#39;s those ones I was thinking of. <br/>&gt; <br/>&gt; -- <br/>&gt; Paul &quot;LeoNerd&quot; Evans <br/>&gt; <br/>&gt; leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS <br/>&gt; http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ <br/>&gt; <br/> <br/>-- <br/>-- <br/>oodler@cpan.org <br/>oodler577@sdf-eu.org <br/>SDF-EU Public Access UNIX System - http://sdfeu.org <br/>irc.perl.org #openmp #pdl #native <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265194.html Sun, 04 Dec 2022 22:39:25 +0000 Re: Deprecation of smartmatch by Martijn Lievaart [ resend, sent it to Paul instead of p5p, sorry Paul ]<br/><br/><br/>Op 02-12-2022 om 18:38 schreef Paul &quot;LeoNerd&quot; Evans:<br/><br/>&gt; * The `in` meta-operator<br/>&gt; https://metacpan.org/pod/Syntax::Operator::In<br/>&gt;<br/>&gt; One thing people liked to use `~~` for is to ask &quot;is this value a<br/>&gt; member of that list of values?&quot;; a sortof set-element-of operator.<br/>&gt; While it&#39;s been possible to ask this question using List::Util::any<br/>&gt; ever since perl 5.6 (and likely before - I don&#39;t remember that far<br/>&gt; back in time), people still aren&#39;t satisfied with that notation:<br/>&gt;<br/>&gt; if($x ~~ @numbers) { ... }<br/>&gt; if(any { $x == $_ } @numbers) { ... }<br/>&gt;<br/>&gt; For those folks, I have written an `in` meta-operator. Motivated in<br/>&gt; much the same way as match/case above, there can be no ambiguity on<br/>&gt; &quot;is this matching with number or string equality here?&quot; because it<br/>&gt; says right upfront in the operator name itself. You tell it - `==`<br/>&gt; or `eq`.<br/>&gt;<br/>&gt; if($x in:== @numbers) { ... }<br/><br/><br/>A thought occured to me of a possible problem here. Consider:<br/><br/> &nbsp;&nbsp;&nbsp; $its_in = $needle in:=~ qr/haystack/;<br/><br/>v.s.<br/><br/> &nbsp;&nbsp;&nbsp; $its_in = $needle in:&lt; @haystack;<br/><br/>Wouldn&#39;t the first to be the RHS of the op, and the second the LHS? <br/>Wouldn&#39;t this create a problem? Or do I simply misunderstand?<br/><br/><br/>M4<br/><br/><br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265193.html Sun, 04 Dec 2022 14:08:58 +0000 Re: Deprecation of smartmatch by Martijn Lievaart Op 02-12-2022 om 18:38 schreef Paul &quot;LeoNerd&quot; Evans:<br/>&gt;<br/>&gt; I believe that, between them, this set of ideas and syntax could be a<br/>&gt; useful addition to the Perl language, as a much more predictable and<br/>&gt; controllable alternative to smartmatch.<br/>&gt;<br/><br/>Wouldn&#39;t this syntax be worthwhile to be generalised, so it can be used <br/>for user defined subs as well?<br/><br/><br/>F.i.<br/><br/>sub my_in($needle :use($op), @haystack)<br/><br/>{<br/><br/> &nbsp;&nbsp;&nbsp; for (@haystack) {<br/><br/> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return $_ if $_ :$op $needle;<br/><br/>}<br/><br/><br/>Note this is a brainstorm idea, the above has some obvious problems. <br/>First there is a syntax problem, as written it clashes with ternaries. <br/>Secondly, different operations would need $needle to be either on the <br/>LHS or RHS, but I already mailed about that in another separate mail, <br/>better to discuss that problem there first.<br/><br/><br/>Obviously it would be great if this would be somewhere in the future. I <br/>bring it up now because if we want it, it might have effect on the <br/>syntax of the currently proposed &#39;in&#39;.<br/><br/><br/>HTH,<br/><br/>M4<br/><br/><br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265192.html Sun, 04 Dec 2022 10:20:53 +0000 Re: Deprecation of smartmatch by "Ruud H.G. van Tol" via perl5-porters <br/>On 2022-12-02 21:11, Darren Duncan wrote:<br/><br/>&gt; [...]<br/>&gt; So in summary, I agree with the match-case and eqv/=== additions to <br/>&gt; core, but I feel the &quot;in&quot; should be left for the likes of List::Util. <br/>&gt; The first 2 have a high win for core syntax AND they are relatively <br/>&gt; uncomplicated, while the last 1 is a lot more complicated in its <br/>&gt; variants and best left in modules, albeit possibly core-bundled modules.<br/><br/>I&#39;d love to have the &#39;in&#39; into Perl, with a default of &#39;eq&#39;, much like <br/>how &#39;sort&#39; defaults to &#39;cmp&#39;.<br/><br/>And I still mourn for &#39;dor&#39; to not be there yet.<br/><br/>-- Ruud<br/><br/>P.S. I always rejected usage of: lexical_topic; switch; indirect; <br/>multidimensional; bareword_filehandles; looks_like_number; $@ checks.<br/><br/>I strongly support weeding out value-based semantics, like is done with <br/>bitwise. And I&#39;m longing for more mature signatures, so I no longer have <br/>to code like \my($x,$y)=\(@_);<br/>:)<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265191.html Sat, 03 Dec 2022 14:24:11 +0000 Re: Compiletime-only lexical hints by Paul "LeoNerd" Evans On Sat, 3 Dec 2022 13:43:15 +0100 <br/>demerphq &lt;demerphq@gmail.com&gt; wrote: <br/> <br/>&gt; Isn&#39;t the problem that there is no clear compiletime/runtime <br/>&gt; distinction in perl? Code could be evaled in any block that needs to <br/>&gt; know the hints in effect. Isnt that the whole point? <br/>&gt; <br/>&gt; Eg, using the regex debugger is managed by hints. You expect this to <br/>&gt; trigger the regex debugger: <br/>&gt; <br/>&gt; my $pattern; <br/>&gt; my $qr= do { <br/>&gt; use re &#39;debug&#39;; <br/>&gt; eval &#39;qr/$pattern/&#39;; <br/>&gt; }; <br/>&gt; <br/>&gt; So if the hints arent frozen at opcode production time, if the opcodes <br/>&gt; produce more opcodes they will have the wrong hints.. <br/> <br/>Right; that&#39;s an example of a hint that definitely should be frozen for <br/>runtime so that eval() can re&ouml;pen it again later on. That&#39;s definitely <br/>fine. <br/> <br/>Many of my modules (ab)use the hints hash to store data between parts <br/>of their own compilation, having no further need for it at runtime. <br/>It&#39;s those ones I was thinking of. <br/> <br/>-- <br/>Paul &quot;LeoNerd&quot; Evans <br/> <br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS <br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265190.html Sat, 03 Dec 2022 13:15:49 +0000 Re: Compiletime-only lexical hints by demerphq On Sat, 3 Dec 2022 at 12:12, Paul &quot;LeoNerd&quot; Evans<br/>&lt;leonerd@leonerd.org.uk&gt; wrote:<br/>&gt;<br/>&gt; BACKGROUND:<br/>&gt; The &quot;lexical hints hash&quot; (`%^H` in Perl, `GvHV(PL_hintgv)` in C) is a<br/>&gt; hash whose contents are effectively scoped to a lexical block. Any<br/>&gt; values added or changed during compilation of the code will be<br/>&gt; restored again at the end of the block that added them. This is<br/>&gt; useful for storing all kinds of lexical state information, often in<br/>&gt; association with compiletime features, additional syntax from CPAN<br/>&gt; modules, etc etc.<br/>&gt;<br/>&gt; The state of this hash is stored in the generated optree of the code,<br/>&gt; so that at runtime the `caller` core op can obtain it. This is used as<br/>&gt; the value of the [10]&#39;th return value from the caller() list.<br/>&gt;<br/>&gt; Technically speaking, *the* values of the hints hash are not in fact<br/>&gt; kept around until runtime. It is in fact frozen into a different<br/>&gt; representation for various reasons unimportant to this conversation,<br/>&gt; except for the fact that this encoding process takes time to<br/>&gt; calculate and the result must be stored somewhere in memory.<br/>&gt;<br/>&gt; Often it turns out that the lexical hints hash is only used for<br/>&gt; compile-time purposes. In fact, across all of my CPAN modules that use<br/>&gt; it (probably at least 10 or so), I use it *exclusively* during<br/>&gt; compiletime. Usually it&#39;s there simply to store an &quot;is this keyword<br/>&gt; enabled?&quot; flag to tell the keyword plugin hooks whether they should be<br/>&gt; active or not. There is absolutely no need for the values I put into it<br/>&gt; to be kept around until runtime, because nothing would ever query it.<br/>&gt;<br/>&gt; There is a CPU-time cost in calculating the frozen representation, and<br/>&gt; a memory cost of storing it in the optree. I would like to find a way<br/>&gt; to remove this cost for keys that don&#39;t need it.<br/>&gt;<br/>&gt;<br/>&gt; I wonder if a really simple effective solution would be to say<br/>&gt; something like<br/>&gt;<br/>&gt; &quot;If the key in the hints hash begins with the character &#39;!&#39; then it<br/>&gt; is omitted from the optree freezing process, and does not appear in<br/>&gt; the runtime-stored copy of the hints.&quot;<br/>&gt;<br/>&gt; I highly doubt that any existing CPAN module uses a key beginning with<br/>&gt; &#39;!&#39; as the convention is that modules should begin the key with their<br/>&gt; own module name, and module names don&#39;t start with &#39;!&#39;.<br/>&gt;<br/>&gt; This idea would be simple and easy for existing modules to adopt,<br/>&gt; because it doesn&#39;t involve adding any new API functions or fields<br/>&gt; (which would mean modules using it can no longer compile on older<br/>&gt; perls). All they&#39;d have to do is prefix the symbol &#39;!&#39; on any key they<br/>&gt; don&#39;t need at runtime (which is likely to be most of them) and on perls<br/>&gt; newer than 5.37.whatever, they&#39;ll gain that CPU and memory saving. Of<br/>&gt; course it won&#39;t do anything on older perls, but that&#39;s fine - the code<br/>&gt; will still compile and the code will continue to work just as it used<br/>&gt; to.<br/>&gt;<br/>&gt;<br/>&gt; Can anyone think of a problem with this? If not, I&#39;ll probably have a<br/>&gt; go at writing a quick PR on it next week.<br/><br/>Isn&#39;t the problem that there is no clear compiletime/runtime<br/>distinction in perl? Code could be evaled in any block that needs to<br/>know the hints in effect. Isnt that the whole point?<br/><br/>Eg, using the regex debugger is managed by hints. You expect this to<br/>trigger the regex debugger:<br/><br/>my $pattern;<br/>my $qr= do {<br/> use re &#39;debug&#39;;<br/> eval &#39;qr/$pattern/&#39;;<br/>};<br/><br/>So if the hints arent frozen at opcode production time, if the opcodes<br/>produce more opcodes they will have the wrong hints..<br/><br/>Yves<br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265189.html Sat, 03 Dec 2022 12:43:36 +0000 Compiletime-only lexical hints by Paul "LeoNerd" Evans BACKGROUND:<br/> The &quot;lexical hints hash&quot; (`%^H` in Perl, `GvHV(PL_hintgv)` in C) is a<br/> hash whose contents are effectively scoped to a lexical block. Any<br/> values added or changed during compilation of the code will be<br/> restored again at the end of the block that added them. This is<br/> useful for storing all kinds of lexical state information, often in<br/> association with compiletime features, additional syntax from CPAN<br/> modules, etc etc.<br/><br/> The state of this hash is stored in the generated optree of the code,<br/> so that at runtime the `caller` core op can obtain it. This is used as<br/> the value of the [10]&#39;th return value from the caller() list.<br/><br/> Technically speaking, *the* values of the hints hash are not in fact<br/> kept around until runtime. It is in fact frozen into a different<br/> representation for various reasons unimportant to this conversation,<br/> except for the fact that this encoding process takes time to<br/> calculate and the result must be stored somewhere in memory.<br/><br/>Often it turns out that the lexical hints hash is only used for<br/>compile-time purposes. In fact, across all of my CPAN modules that use<br/>it (probably at least 10 or so), I use it *exclusively* during<br/>compiletime. Usually it&#39;s there simply to store an &quot;is this keyword<br/>enabled?&quot; flag to tell the keyword plugin hooks whether they should be<br/>active or not. There is absolutely no need for the values I put into it<br/>to be kept around until runtime, because nothing would ever query it.<br/><br/>There is a CPU-time cost in calculating the frozen representation, and<br/>a memory cost of storing it in the optree. I would like to find a way<br/>to remove this cost for keys that don&#39;t need it.<br/><br/><br/>I wonder if a really simple effective solution would be to say<br/>something like<br/><br/> &quot;If the key in the hints hash begins with the character &#39;!&#39; then it<br/> is omitted from the optree freezing process, and does not appear in<br/> the runtime-stored copy of the hints.&quot;<br/><br/>I highly doubt that any existing CPAN module uses a key beginning with<br/>&#39;!&#39; as the convention is that modules should begin the key with their<br/>own module name, and module names don&#39;t start with &#39;!&#39;.<br/><br/>This idea would be simple and easy for existing modules to adopt,<br/>because it doesn&#39;t involve adding any new API functions or fields<br/>(which would mean modules using it can no longer compile on older<br/>perls). All they&#39;d have to do is prefix the symbol &#39;!&#39; on any key they<br/>don&#39;t need at runtime (which is likely to be most of them) and on perls<br/>newer than 5.37.whatever, they&#39;ll gain that CPU and memory saving. Of<br/>course it won&#39;t do anything on older perls, but that&#39;s fine - the code<br/>will still compile and the code will continue to work just as it used<br/>to.<br/><br/><br/>Can anyone think of a problem with this? If not, I&#39;ll probably have a<br/>go at writing a quick PR on it next week.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265188.html Sat, 03 Dec 2022 11:12:35 +0000 Perl 5 Commit Summary by Perl 5 commit summary Perl 5 commit summary, activity since Wednesday<br/><br/>Current branch blead<br/>15 commits. 6 unique authors. 5 unique committers.<br/>16 files changed, 447 insertions(+), 405 deletions(-)<br/>Thanks, applied: Paul Evans (2) xenu (1) Karl Williamson (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/4d21c0264d5bef34<br/><br/> locale.c: Create a convenience #define<br/> Karl Williamson 1 file changed, 10 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/4d21c0264d5bef34<br/><br/> locale.c: Rmv unnecessary parameter from static function<br/> Karl Williamson 4 files changed, 6 insertions(+), 11 deletions(-<br/> https://github.com/Perl/perl5/commit/5351ec0e1c39a301<br/><br/> locale.c white-space, comment, pod, C99 only<br/> Karl Williamson 1 file changed, 230 insertions(+), 220 deletions<br/> https://github.com/Perl/perl5/commit/4c39aaa2805d71d6<br/><br/> locale.c Move some code to more appropriate place<br/> Karl Williamson 1 file changed, 6 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/04e87daf1046533c<br/><br/> POSIX::localeconv: Return empty/special values<br/> Karl Williamson 2 files changed, 5 insertions(+), 9 deletions(-)<br/> https://github.com/Perl/perl5/commit/04de0222db2c455e<br/><br/> locale.c: Save to proper buffer<br/> Karl Williamson 1 file changed, 1 insertion(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/f42fb42da6158a7a<br/><br/> pp_sort: don&#39;t force inline the comparison functions<br/> Tony Cook 2 files changed, 28 insertions(+), 56 deletions(<br/> https://github.com/Perl/perl5/commit/f5a18896dd41b93e<br/><br/> Document postderef_qq support for -&gt;$#* interpolation<br/> Zakariyya Mughal 3 files changed, 11 insertions(+), 7 deletions(-<br/> https://github.com/Perl/perl5/commit/365f3e0f038557f2<br/><br/> feature.pm: Bump version number<br/> Karl Williamson 2 files changed, 2 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/e5bd4888f2823c6f<br/><br/> Bump B::Deparse VERSION<br/> Paul &quot;LeoNerd&quot; Evans 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/174ad045483d7ef2<br/><br/> Deparse.pm: Correctly handle signature //= and ||= params<br/> Paul &quot;LeoNerd&quot; Evans 2 files changed, 21 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/16ab164090761445<br/><br/> pod2html: sort command-line switches<br/> James E Keenan 1 file changed, 77 insertions(+), 78 deletions(-<br/> https://github.com/Perl/perl5/commit/74138d37463ce032<br/><br/> perl.c - move PL_restartop assert out of perl_run()<br/> Yves Orton 3 files changed, 45 insertions(+), 8 deletions(-<br/> https://github.com/Perl/perl5/commit/ce3819cf202a3c5c<br/><br/> regen.pl - add miniperlmain.pl, it is fast, and doesn&#39;t hurt<br/> Yves Orton 2 files changed, 2 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/c9c8e2368deb1a7e<br/><br/> regen.pl - sort list of regen plug ins<br/> Yves Orton 1 file changed, 3 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/e7f0696486ec657c<br/><br/>Current branch smoke-me/khw-threads<br/>32 commits. 1 unique author. 1 unique committer.<br/>22 files changed, 233 insertions(+), 303 deletions(-)<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/7062ce3fd286ae08<br/><br/> no querylocale on darwin<br/> Karl Williamson 1 file changed, 1 insertion(+)<br/> https://github.com/Perl/perl5/commit/7062ce3fd286ae08<br/><br/> makedef<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/4c47e337dab55841<br/><br/> extraneous endif<br/> Karl Williamson 1 file changed, 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/6fe9612fb443eb0d<br/><br/> more fixup<br/> Karl Williamson 3 files changed, 6 insertions(+), 7 deletions(-)<br/> https://github.com/Perl/perl5/commit/29205d56bd13966c<br/><br/> fixup<br/> Karl Williamson 2 files changed, 3 insertions(+)<br/> https://github.com/Perl/perl5/commit/862b33d98c35dc66<br/><br/> sleep<br/> Karl Williamson 1 file changed, 4 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/c5d19a1bdd961eab<br/><br/> locale_threads<br/> Karl Williamson 1 file changed, 11 insertions(+), 11 deletions(-<br/> https://github.com/Perl/perl5/commit/c071c0e5e0ece642<br/><br/> no langinfo on darwin<br/> Karl Williamson 1 file changed, 3 insertions(+)<br/> https://github.com/Perl/perl5/commit/11e0ce5b7e835765<br/><br/> help<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/8b6f9dbbfff240c6<br/><br/> XXX threads NON_tTHX leak maybe fix breakage<br/> Karl Williamson 3 files changed, 4 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/bb43b8f8c0bd7b29<br/><br/> locale_threads<br/> Karl Williamson 1 file changed, 1421 insertions(+), 53 deletions<br/> https://github.com/Perl/perl5/commit/e13c98e43f8b5458<br/><br/> locale.c: If not compiling locales, can&#39;t have UTF-8 ones<br/> Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/35bf8e7a5d651626<br/><br/> locale.c: Silence compiler warning<br/> Karl Williamson 1 file changed, 2 insertions(+)<br/> https://github.com/Perl/perl5/commit/0733b16645d2e70f<br/><br/> XXX querylocale<br/> Karl Williamson 4 files changed, 59 insertions(+), 40 deletions(<br/> https://github.com/Perl/perl5/commit/bf4b92c3b33b71ae<br/><br/> XXX win workaround<br/> Karl Williamson 1 file changed, 39 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/427e307fdf7a6178<br/><br/> locale.c: Rewrite localeconv() handling<br/> Karl Williamson 5 files changed, 567 insertions(+), 399 deletion<br/> https://github.com/Perl/perl5/commit/85ccce676bade287<br/><br/> locale.c: Remove use of localeconv_l()<br/> Karl Williamson 1 file changed, 13 insertions(+), 53 deletions(-<br/> https://github.com/Perl/perl5/commit/453e6ed56b544dbc<br/><br/> locale.c: Move 2 functions elsewhere in the code<br/> Karl Williamson 4 files changed, 135 insertions(+), 138 deletion<br/> https://github.com/Perl/perl5/commit/97b4c76f13756dd8<br/><br/> locale.c: Create #define for a particular #if combo<br/> Karl Williamson 1 file changed, 10 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/71dc169dfe1b2b18<br/><br/> locale.c: Prepare get_locale_string_utf8ness_i for no locales<br/> Karl Williamson 1 file changed, 15 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/64845b3279d9a68c<br/><br/> loc_tools.pl: Always do normalized locale name check<br/> Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/1974eac61e19db0b<br/><br/> loc_tools.pl: Accept dashless UTF8 besides to &#39;UTF-8&#39;<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/90beae9e1d29f8c8<br/><br/> Don&#39;t use Vietnamese locale on Solaris<br/> Karl Williamson 1 file changed, 1 insertion(+)<br/> https://github.com/Perl/perl5/commit/3986c9f2dc837088<br/><br/> loc_tools.pl: Add ability to skip known bad locales<br/> Karl Williamson 1 file changed, 9 insertions(+)<br/> https://github.com/Perl/perl5/commit/129889cd42f1c264<br/><br/> util.c: Remove unnecessary #ifdef<br/> Karl Williamson 1 file changed, 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/a1d6ad3fd8c8db86<br/><br/> XXX memlog<br/> Karl Williamson 3 files changed, 6 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/06b4c43fbe7eb92b<br/><br/> locale.c: Reorder parameters to static function<br/> Karl Williamson 3 files changed, 39 insertions(+), 33 deletions(<br/> https://github.com/Perl/perl5/commit/c3be67000c83f2b5<br/><br/> locale.c: Rmv unnecessary parameter from static function<br/> Karl Williamson 4 files changed, 6 insertions(+), 11 deletions(-<br/> https://github.com/Perl/perl5/commit/7c974738a356fa35<br/><br/> wrap<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/cd048dddeaeae37c<br/><br/> XXX perl.h: Debugging mutex lock&#39;<br/> Karl Williamson 1 file changed, 17 insertions(+)<br/> https://github.com/Perl/perl5/commit/6d3d8d177458ddd1<br/><br/> use mvrtowc lock<br/> Karl Williamson 1 file changed, 7 insertions(+)<br/> https://github.com/Perl/perl5/commit/614703e0627050df<br/><br/> XXX flesh out msg: Add STDIZED_MUTEX_LOCK<br/> Karl Williamson 2 files changed, 47 insertions(+), 17 deletions(<br/> https://github.com/Perl/perl5/commit/06c51986259f5da3<br/><br/>New branch yves/fix_double_fetch<br/>2 commits. 1 unique author. 1 unique committer.<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/56394338bd9d827b<br/><br/> lib/overload.t - fix test<br/> Yves Orton 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/56394338bd9d827b<br/><br/> Fix double FETCH from tied overloaded scalar<br/> Yves Orton 1 file changed, 10 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/da76928798ede6f5<br/><br/>Deleted branch yves/fix_20557_perl_run_assert<br/><br/>Martian commit d68070420a71f4b408e107adbe529ce93ce22669<br/>1 commit. 1 unique author. 1 unique committer.<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/d68070420a71f4b4<br/><br/> locale.c: Save to proper buffer<br/> Karl Williamson 1 file changed, 1 insertion(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/d68070420a71f4b4<br/><br/>Martian commit d662680668f84bcd89d6ac99da4dfe4690d3ed7f<br/>1 commit. 1 unique author. 1 unique committer.<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/d662680668f84bcd<br/><br/> POSIX::localeconv: Return empty/special values<br/> Karl Williamson 2 files changed, 5 insertions(+), 9 deletions(-)<br/> https://github.com/Perl/perl5/commit/d662680668f84bcd<br/><br/>Martian commit c71fca5551ae3cddfff46b88c36dfb2829e37430<br/>1 commit. 1 unique author. 1 unique committer.<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/c71fca5551ae3cdd<br/><br/> pp_sort.c: move the definitions of comparators<br/> Tomasz Konojacki 1 file changed, 649 insertions(+), 650 deletions<br/> https://github.com/Perl/perl5/commit/c71fca5551ae3cdd<br/><br/>Ignored 69 GitHub auto-generated merge commits<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265187.html Sat, 03 Dec 2022 03:05:34 +0000 Re: Deprecation of smartmatch by Darren Duncan On 2022-12-02 9:38 a.m., Paul &quot;LeoNerd&quot; Evans wrote:<br/>&gt; ... new pair of<br/>&gt; keywords used in a similar style to given/when ... use an operator<br/>&gt; that the programmer specified upfront. That way, there can be no<br/>&gt; surprises that it does &quot;odd things&quot; when it encounters some weird<br/>&gt; value you weren&#39;t expecting. If you expected string equality<br/>&gt; matching, you *know* you are getting string equality matching<br/>&gt; because it says so right there:<br/>&gt; <br/>&gt; my $var = &quot;abc&quot;;<br/>&gt; match($var : eq) {<br/>&gt; case(&quot;abc&quot;) { $ok++ }<br/>&gt; case(&quot;def&quot;) { fail(&#39;Not this one sorry&#39;); }<br/>&gt; }<br/><br/>I agree fully that this is the right way to go.<br/><br/>I would further say that it must be mandatory for the programmer to specify the <br/>comparison operator to use. There must not be an implicit default for leaving <br/>that out, because this would be full of surprises, saving a few characters isn&#39;t <br/>worth the ambiguity.<br/><br/>I will also add that this construct must be generalized enough to support <br/>anonymous inline defined operators such as map/grep/sort/etc do with their block <br/>syntaxes, and that this is not limited to things for which an infix operator <br/>syntax exists.<br/><br/>One can bikeshed the exact syntax.<br/><br/>&gt; ... a sortof set-element-of operator ... `in` meta-operator. Motivated in<br/>&gt; much the same way as match/case above, there can be no ambiguity on<br/>&gt; &quot;is this matching with number or string equality here?&quot; because it<br/>&gt; says right upfront in the operator name itself. You tell it - `==`<br/>&gt; or `eq`.<br/>&gt; <br/>&gt; if($x in:== @numbers) { ... }<br/><br/>I also like this idea, especially the programmer-defined operator to use. And <br/>everything I said about mandatoryness and anonymous operators applies here too. <br/>But in contrast to the switch-case type expression above, this list membership <br/>thing may be best to remain a module without dedicated language syntax, because <br/>there are many variations or list operations that it would be good to have that <br/>flexibility with, and it would be hard to pick a good set for core, and special <br/>syntax doesn&#39;t really add much over List::Util etc, or maybe such syntax should <br/>be a List::Util enhancement instead.<br/><br/>&gt; ... `equ` and `===`, which<br/>&gt; are slight variants of the familiar `eq` and `==` but which consider<br/>&gt; undef to be a distinct value separate from empty or zero.<br/>&gt; <br/>&gt; if($n === 0) { say &quot;n is zero&quot; }<br/>&gt; else { say &quot;n is undefined, or non-zero&quot; }<br/>&gt; <br/>&gt; Useful on their own perhaps, but they become more useful when you<br/>&gt; realise you can use them with `match` or `in`:<br/><br/>I agree that having these undef-distinguishing variants would be a very good <br/>thing to have in core contemporary to `eq` and `==`. One might bikeshed on <br/>their syntax, but in principle taking the existing operator names and adding 1 <br/>character for the variant seems to be an elegant choice.<br/><br/>So in summary, I agree with the match-case and eqv/=== additions to core, but I <br/>feel the &quot;in&quot; should be left for the likes of List::Util. The first 2 have a <br/>high win for core syntax AND they are relatively uncomplicated, while the last 1 <br/>is a lot more complicated in its variants and best left in modules, albeit <br/>possibly core-bundled modules.<br/><br/>-- Darren Duncan<br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265186.html Fri, 02 Dec 2022 20:12:07 +0000 Re: Deprecation of smartmatch by Paul "LeoNerd" Evans On Fri, 2 Dec 2022 16:12:35 +0000<br/>&quot;Paul \&quot;LeoNerd\&quot; Evans&quot; &lt;leonerd@leonerd.org.uk&gt; wrote:<br/><br/>&gt; [With my PSC hat on]<br/>...<br/>&gt; We also aim to provide some thoughts on what new features may be added<br/>&gt; to Perl in the future to provide a better solution to these common<br/>&gt; situations that smartmatch and `given/when` are currently used for.<br/><br/>[And now with my personal hat on. These are just my own thoughts and<br/>not the collected decisions of the PSC as a whole.]<br/><br/>I&#39;ve been working on a number of CPAN module that implement syntax<br/>extensions, which could be good design candidates for something to<br/>provide in core.<br/><br/>Each of these has been designed, not to be a *total* replacement of<br/>everything that smartmatch or given/when can do (because indeed, most<br/>of the problem with them is the huge wide-ranging set of conflicting<br/>features and behaviours they had), but instead to attack one small<br/>specific problem area and find a nice neat solution to *that* problem<br/>in a way that can be combined with the others, in programmer-controlled<br/>(rather than runtime value-controlled) ways.<br/><br/> * The `match/case` statement<br/> https://metacpan.org/pod/Syntax::Keyword::Match<br/><br/> The main use-case for given/when is to ask the question &quot;does this<br/> scalar value match any of these possible things?&quot; - much like a<br/> C-style switch statement. For this scenario, I imagined a new pair of<br/> keywords used in a similar style to given/when. A key difference<br/> here is that they don&#39;t use smartmatch, but instead use an operator<br/> that the programmer specified upfront. That way, there can be no<br/> surprises that it does &quot;odd things&quot; when it encounters some weird<br/> value you weren&#39;t expecting. If you expected string equality<br/> matching, you *know* you are getting string equality matching<br/> because it says so right there:<br/><br/> my $var = &quot;abc&quot;;<br/> match($var : eq) {<br/> case(&quot;abc&quot;) { $ok++ }<br/> case(&quot;def&quot;) { fail(&#39;Not this one sorry&#39;); }<br/> }<br/><br/> * The `in` meta-operator<br/> https://metacpan.org/pod/Syntax::Operator::In<br/><br/> One thing people liked to use `~~` for is to ask &quot;is this value a<br/> member of that list of values?&quot;; a sortof set-element-of operator.<br/> While it&#39;s been possible to ask this question using List::Util::any<br/> ever since perl 5.6 (and likely before - I don&#39;t remember that far<br/> back in time), people still aren&#39;t satisfied with that notation:<br/><br/> if($x ~~ @numbers) { ... }<br/> <br/> if(any { $x == $_ } @numbers) { ... }<br/><br/> For those folks, I have written an `in` meta-operator. Motivated in<br/> much the same way as match/case above, there can be no ambiguity on<br/> &quot;is this matching with number or string equality here?&quot; because it<br/> says right upfront in the operator name itself. You tell it - `==`<br/> or `eq`.<br/><br/> if($x in:== @numbers) { ... }<br/><br/> * The `equ` and `===` operators<br/> https://metacpan.org/pod/Syntax::Operator::Equ<br/><br/> Once the above things are taken into account, there isn&#39;t much left<br/> that&#39;s &quot;obvious&quot; about smartmatch or given/when, that isn&#39;t already<br/> handled. One remaining problem is that given/when and smartmatch can<br/> distinguish undef from both the number zero and the empty string.<br/> Neither of the above things can do that.<br/><br/> For this problem I imagined two new operators, `equ` and `===`, which<br/> are slight variants of the familiar `eq` and `==` but which consider<br/> undef to be a distinct value separate from empty or zero.<br/><br/> if($n === 0) { say &quot;n is zero&quot; }<br/> else { say &quot;n is undefined, or non-zero&quot; }<br/><br/> Useful on their own perhaps, but they become more useful when you<br/> realise you can use them with `match` or `in`:<br/><br/> match($x : equ) {<br/> case(undef) { say &quot;x is undef&quot; }<br/> case(&quot;&quot;) { say &quot;x is the empty string&quot; }<br/> default { say &quot;x is a non-empty string&quot; }<br/> }<br/><br/> if($x in:=== (0..9)) { say &quot;x is a defined single-digit number&quot; }<br/><br/><br/>To recap on above: This set of ideas isn&#39;t supposed to cover every<br/>possible use-case of smartmatch and given/when. Rather, it is intended<br/>to cover a wide range of practical useful things that people *actually*<br/>use the syntax for. Each was designed in the face of real practical<br/>problems. Furthermore, match/case is already in use in a number of CPAN<br/>modules, and actual real-world programs that I run all the time:<br/><br/> https://metacpan.org/module/Syntax::Keyword::Match/requires<br/><br/>I believe that, between them, this set of ideas and syntax could be a<br/>useful addition to the Perl language, as a much more predictable and<br/>controllable alternative to smartmatch.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265185.html Fri, 02 Dec 2022 17:39:09 +0000 Re: Deprecation of smartmatch by Scott Baker RIP Smartmatch<br/><br/>On 12/2/2022 8:12 AM, Paul &quot;LeoNerd&quot; Evans wrote:<br/>&gt; [With my PSC hat on]<br/>&gt;<br/>&gt; In Perl 5.10 we added `~~`, known as smartmatch, as a sort-of copy of<br/>&gt; what is now in Raku (known as &quot;Perl 6&quot; at the time). Initially looked<br/>&gt; at favourably, design problems were eventually found around it that<br/>&gt; mean it is a poor match for the different type system that Perl 5 has.<br/>&gt; This operator (and the related `given/when` syntax) sat in<br/>&gt; &quot;experimental&quot; status ever since Perl 5.18, while we attempted to work<br/>&gt; out what to do with it.<br/>&gt;<br/>&gt; The time has now come to finally declare an end to this experiment. It<br/>&gt; has not been possible to provide a meaningful, coherent set of<br/>&gt; semantics for this operator that sits well with users. Because of this,<br/>&gt; we feel it best to move the operator into &quot;deprecated&quot; status,<br/>&gt; announcing that we *will* be removing it in a later version of perl.<br/>&gt; This is currently scheduled for two releases later (Perl 5.42 in the<br/>&gt; current schedule).<br/>&gt;<br/>&gt; By the time that Perl 5.38 is released, we aim to have some updated<br/>&gt; documentation that explains the deprecated feature and the reasons<br/>&gt; behind it, and also gives advice to users who are already using this<br/>&gt; syntax on what they can write instead to replace it.<br/>&gt;<br/>&gt; We also aim to provide some thoughts on what new features may be added<br/>&gt; to Perl in the future to provide a better solution to these common<br/>&gt; situations that smartmatch and `given/when` are currently used for.<br/>&gt;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265184.html Fri, 02 Dec 2022 17:29:51 +0000 Re: PSC #089: 2022-12-02 by Paul "LeoNerd" Evans On Fri, 2 Dec 2022 11:55:45 -0500 <br/>Felipe Gasper &lt;felipe@felipegasper.com&gt; wrote: <br/> <br/>&gt; &gt; These are items that seem generally popular as things people would <br/>&gt; &gt; like to use, but with nobody working on implementing, they are <br/>&gt; &gt; likely to fall off the tracker at some point in the near future. <br/>&gt; &gt; Volunteers welcome? &#x1F642; <br/>&gt; <br/>&gt; Are there write-ups that detail the actual help needed with these? <br/> <br/>&quot;Design work is all done. Take a branch of bleadperl, implement it, <br/>submit a PR&quot;. <br/> <br/>Basically ;) <br/> <br/>-- <br/>Paul &quot;LeoNerd&quot; Evans <br/> <br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS <br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265183.html Fri, 02 Dec 2022 16:59:21 +0000 Re: PSC #089: 2022-12-02 by Felipe Gasper <br/>&gt; On Dec 2, 2022, at 11:50, Ricardo Signes &lt;perl.p5p@rjbs.manxome.org&gt; wrote: <br/>&gt; <br/>&gt; Porters, <br/>&gt; <br/>&gt; Philippe and Paul and I met today to discuss things. <br/>&gt; <br/>&gt; We posted the smartmatch deprecation message to p5p@; will post it to blogs etc.. after a round of responses. <br/>&gt; <br/>&gt; We sent off a reminder that we&#39;re looking for help or a project manager on getting SSL support out of the box. <br/> <br/>Is there a thread about this? I&rsquo;m curious what this would entail. I assume that the &ldquo;target&rdquo; SSL support stack is just Net::SSLeay, IO::Socket::SSL, and the system&rsquo;s root store? <br/> <br/>&gt; We reviewed the RFC tracker and found some that are nearing their expiration date: <br/>&gt; &bull; ${^ENGLISH_NAME} aliases for punctuation variables <br/>&gt; &bull; Optional chaining <br/>&gt; &bull; Drop support for &#39; as package name separator <br/>&gt; &bull; Template Strings (qt) <br/>&gt; These are items that seem generally popular as things people would like to use, but with nobody working on implementing, they are likely to fall off the tracker at some point in the near future. Volunteers welcome? &#x1F642; <br/> <br/>Are there write-ups that detail the actual help needed with these? <br/> <br/>-FG <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265182.html Fri, 02 Dec 2022 16:56:02 +0000 PSC #089: 2022-12-02 by Ricardo Signes Porters, <br/> <br/>Philippe and Paul and I met today to discuss things. <br/> <br/>We posted the smartmatch deprecation message to p5p@; will post it to blogs etc.. after a round of responses. <br/> <br/>We sent off a reminder that we&#39;re looking for help or a project manager on getting SSL support out of the box. <br/> <br/>We reviewed the RFC tracker and found some that are nearing their expiration date: <br/> * ${^ENGLISH_NAME} aliases for punctuation variables <br/> * Optional chaining <br/> * Drop support for &#39; as package name separator <br/> * Template Strings (qt) <br/>These are items that seem generally popular as things people would like to use, but with nobody working on implementing, they are likely to fall off the tracker at some point in the near future. Volunteers welcome? &#x1F642; <br/> <br/>-- <br/>rjbs https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265181.html Fri, 02 Dec 2022 16:51:11 +0000 Deprecation of smartmatch by Paul "LeoNerd" Evans [With my PSC hat on]<br/><br/>In Perl 5.10 we added `~~`, known as smartmatch, as a sort-of copy of<br/>what is now in Raku (known as &quot;Perl 6&quot; at the time). Initially looked<br/>at favourably, design problems were eventually found around it that<br/>mean it is a poor match for the different type system that Perl 5 has.<br/>This operator (and the related `given/when` syntax) sat in<br/>&quot;experimental&quot; status ever since Perl 5.18, while we attempted to work<br/>out what to do with it.<br/><br/>The time has now come to finally declare an end to this experiment. It<br/>has not been possible to provide a meaningful, coherent set of<br/>semantics for this operator that sits well with users. Because of this,<br/>we feel it best to move the operator into &quot;deprecated&quot; status,<br/>announcing that we *will* be removing it in a later version of perl.<br/>This is currently scheduled for two releases later (Perl 5.42 in the<br/>current schedule).<br/><br/>By the time that Perl 5.38 is released, we aim to have some updated<br/>documentation that explains the deprecated feature and the reasons<br/>behind it, and also gives advice to users who are already using this<br/>syntax on what they can write instead to replace it.<br/><br/>We also aim to provide some thoughts on what new features may be added<br/>to Perl in the future to provide a better solution to these common<br/>situations that smartmatch and `given/when` are currently used for.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265180.html Fri, 02 Dec 2022 16:12:56 +0000 Re: Add Magic type that gets copied at assignement by "Ruud H.G. van Tol" via perl5-porters <br/><br/>On 2022-12-02 12:20, Dave Mitchell wrote:<br/>&gt; On Thu, Dec 01, 2022 at 01:36:39PM +0100, Ruud H.G. van Tol via perl5-porters wrote:<br/>&gt;&gt; For example, and assuming the necessary Trace-attribute-logic is available:<br/>&gt;&gt;<br/>&gt;&gt; my $x :Trace = 42; # gets hound-magic applied<br/>&gt;&gt; my $y = $x; # inherits the hound-magic from $x<br/>&gt;&gt; my $z = $x + $y; # inherits a merge<br/>&gt;&gt;<br/>&gt;&gt; print {$fh} $z; # can complain/fail if the value has incomplete history<br/>&gt; <br/>&gt; It&#39;s unclear to me from your example where the &quot;more than one bit&quot; payload<br/>&gt; is specified, how the multiple hound values are merged into a single value<br/>&gt; on binary or list operations, how it can be examined, and whether/how/when<br/>&gt; perl automatically complains or dies when the hound magic is absent or has<br/>&gt; the wrong value.<br/><br/>IMO that should all be (mostly) left to the user-side.<br/>(if this can be a user-type-Magic,<br/>for example like the one that Variable::Magic uses)<br/><br/>The payload will most likely need to be a hash.<br/>The user can then optimize that payload at will.<br/>(replace values by references, rearrange stuff,<br/>maybe even bless the hashref)<br/><br/>So my example was more about how a user could use it.<br/><br/>The copy-Magic-logic could for example support a callback for such.<br/>Most conveniently with a proper default.<br/><br/>-- Ruud<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265179.html Fri, 02 Dec 2022 12:14:57 +0000 Re: Add Magic type that gets copied at assignement by Dave Mitchell On Thu, Dec 01, 2022 at 01:36:39PM +0100, Ruud H.G. van Tol via perl5-porters wrote:<br/>&gt; For example, and assuming the necessary Trace-attribute-logic is available:<br/>&gt; <br/>&gt; my $x :Trace = 42; # gets hound-magic applied<br/>&gt; my $y = $x; # inherits the hound-magic from $x<br/>&gt; my $z = $x + $y; # inherits a merge<br/>&gt; <br/>&gt; print {$fh} $z; # can complain/fail if the value has incomplete history<br/><br/>It&#39;s unclear to me from your example where the &quot;more than one bit&quot; payload<br/>is specified, how the multiple hound values are merged into a single value<br/>on binary or list operations, how it can be examined, and whether/how/when<br/>perl automatically complains or dies when the hound magic is absent or has<br/>the wrong value.<br/><br/>-- <br/>Wesley Crusher gets beaten up by his classmates for being a smarmy git,<br/>and consequently has a go at making some friends of his own age for a<br/>change.<br/> -- Things That Never Happen in &quot;Star Trek&quot; #18<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265178.html Fri, 02 Dec 2022 11:20:30 +0000 Corinna (OOP) "Quickstart" Tutorial by Ovid Hi all,<br/><br/>Several times I&#39;ve seen variations of &quot;I&#39;ve not really followed the Corinna<br/>project, but ...&quot;. Part of the problem is how long the discussions have<br/>been ongoing and how the information about the different bits are scattered<br/>across various sections of the full RFC<br/>&lt;https://github.com/Ovid/Cor/blob/master/rfc/toc.md&gt;. I previously wanted<br/>to write a &quot;quickstart&quot; guide, but we were in too much flux. Now, I have<br/>one: https://gist.github.com/Ovid/e0381355da7136654e92418a43c97611<br/><br/>It&#39;s in a gist for now because it&#39;s a work in progress and will need<br/>refinement later (and I&#39;ve realized that I can&#39;t easily create perldoc -f<br/>$keyword sections in perlfunc due to the size of the project. Suggestions<br/>on how to organize the POD documents for the new system are welcome. At<br/>minimum, we&#39;ll need separate sections for:<br/><br/><br/> 1. The class keyword<br/> 2. The role keyword<br/> 3. The field keyword<br/> 4. The method keyword<br/> 5. A tutorial<br/><br/>Suggestions welcome.<br/><br/>The guide is not complete, but gives a brief introduction to the four new<br/>keywords, class, role, field, and method. It takes you from &quot;nothing&quot; to<br/>building a simple LRU cache which consumes a role to provide JSON<br/>serialization (the role is simplistic, to be honest).<br/><br/>Best,<br/>Curtis &quot;Ovid&quot; Poe<br/>CTO, All Around the World<br/>World-class software development and consulting<br/>https://allaroundtheworld.fr/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265177.html Fri, 02 Dec 2022 10:02:14 +0000 Re: Pluggable Infix Operators by Paul "LeoNerd" Evans On Mon, 14 Nov 2022 17:45:02 +0000<br/>&quot;Paul \&quot;LeoNerd\&quot; Evans&quot; &lt;leonerd@leonerd.org.uk&gt; wrote:<br/><br/>&gt; On Mon, 24 Oct 2022 23:55:28 +0100<br/>&gt; &quot;Paul \&quot;LeoNerd\&quot; Evans&quot; &lt;leonerd@leonerd.org.uk&gt; wrote:<br/>&gt; <br/>&gt; &gt; The Perl5 branch itself is sitting over here:<br/>&gt; &gt; <br/>&gt; &gt; https://github.com/leonerd/perl5/tree/infix-plugin<br/>&gt; &gt; <br/>&gt; &gt; I wonder how is best to proceed on this...? Should I make a PR yet<br/>&gt; &gt; or would there be larger questions to talk about first? Maybe an RFC<br/>&gt; &gt; even? <br/>&gt; <br/>&gt; Well, nobody really said anything so I have gone ahead and created the<br/>&gt; PR:<br/>&gt; <br/>&gt; https://github.com/Perl/perl5/pull/20512<br/><br/>Does anyone else have an opinion on this PR?<br/><br/>Yves has already said effectively &quot;Eh, fine do it&quot;, which doesn&#39;t feel<br/>like a *very* strong approval yet. ;)<br/><br/>For much of the past decade modules have been able to experiment with<br/>new keywords, which has eventually lead to signatures, try/catch,<br/>defer, and other recent core features. Especially in the face of<br/>removing smartmatch, I&#39;d like to give CPAN equal ability to experiment<br/>with new infix operators, as a lot of these ideas may work nicely with<br/>my match/case idea, as well as on their own.<br/><br/>If nobody has anything actually against it then I would like to merge<br/>it, on basis of &quot;making forward progress&quot;, as it opens the path to<br/>allowing CPAN modules to experiment with new operators.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265176.html Thu, 01 Dec 2022 15:40:30 +0000 Re: Add Magic type that gets copied at assignement by "Ruud H.G. van Tol" via perl5-porters <br/>On 2022-12-01 15:37, Leon Timmermans wrote:<br/>&gt; On Thu, Dec 1, 2022 at 1:37 PM Ruud H.G. van Tol via perl5-porters <br/>&gt; &lt;perl5-porters@perl.org &lt;mailto:perl5-porters@perl.org&gt;&gt; wrote:<br/><br/>&gt;&gt; Recently I hit a need for a (user) Magic type that is contagious,<br/>&gt;&gt; kind of like tainting, but with more payload than a single bit.<br/>&gt;&gt; [...]<br/>&gt; <br/>&gt; I have wanted this before. The question &quot;which values inherit it&quot; is <br/>&gt; quite complicated though, I&#39;m not sure it can be done right in the <br/>&gt; general sense.<br/><br/>In the sense that it needs a lexical override?<br/><br/>Or more basic? Like:<br/><br/>my $x :Trace= 3;<br/>my $y= $thing[ $x ];<br/><br/>-- Ruud<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265175.html Thu, 01 Dec 2022 15:10:12 +0000 Re: Add Magic type that gets copied at assignement by Leon Timmermans On Thu, Dec 1, 2022 at 1:37 PM Ruud H.G. van Tol via perl5-porters &lt;<br/>perl5-porters@perl.org&gt; wrote:<br/><br/>&gt;<br/>&gt; Recently I hit a need for a (user) Magic type that is contagious,<br/>&gt; kind of like tainting, but with more payload than a single bit.<br/>&gt;<br/>&gt; To me it looks surprising that such a Magic was never part of Perl yet,<br/>&gt; so I am probably missing the good reasons for that.<br/>&gt;<br/>&gt; Is there more background on this?<br/>&gt;<br/>&gt; -- -- --<br/>&gt;<br/>&gt; The way I see it done, is through a new -H perlrun flag,<br/>&gt; and, just like with tainting, an opt-in configuration<br/>&gt; option to have it compiled in.<br/>&gt;<br/>&gt; -- -- --<br/>&gt;<br/>&gt; The -H comes from Hound, Hounding. I want to use it<br/>&gt; for Data Lineage, to trace/log/guard the history of a value.<br/>&gt; (but please see that as an XY-remark, where the suggested implementation<br/>&gt; doesn&#39;t need to be the right way to achieve the goal)<br/>&gt;<br/>&gt;<br/>&gt; For example, and assuming the necessary Trace-attribute-logic is available:<br/>&gt;<br/>&gt; my $x :Trace = 42; # gets hound-magic applied<br/>&gt; my $y = $x; # inherits the hound-magic from $x<br/>&gt; my $z = $x + $y; # inherits a merge<br/>&gt;<br/>&gt; print {$fh} $z; # can complain/fail if the value has incomplete history<br/>&gt;<br/>&gt;<br/>&gt; Some of this is achievable with objects and tie,<br/>&gt; but I found that limited (!) and tedious.<br/>&gt;<br/><br/>I have wanted this before. The question &quot;which values inherit it&quot; is quite<br/>complicated though, I&#39;m not sure it can be done right in the general sense.<br/><br/>Leon<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265174.html Thu, 01 Dec 2022 14:37:57 +0000 Add Magic type that gets copied at assignement by "Ruud H.G. van Tol" via perl5-porters <br/>Recently I hit a need for a (user) Magic type that is contagious,<br/>kind of like tainting, but with more payload than a single bit.<br/><br/>To me it looks surprising that such a Magic was never part of Perl yet,<br/>so I am probably missing the good reasons for that.<br/><br/>Is there more background on this?<br/><br/>-- -- --<br/><br/>The way I see it done, is through a new -H perlrun flag,<br/>and, just like with tainting, an opt-in configuration<br/>option to have it compiled in.<br/><br/>-- -- --<br/><br/>The -H comes from Hound, Hounding. I want to use it<br/>for Data Lineage, to trace/log/guard the history of a value.<br/>(but please see that as an XY-remark, where the suggested implementation <br/>doesn&#39;t need to be the right way to achieve the goal)<br/><br/><br/>For example, and assuming the necessary Trace-attribute-logic is available:<br/><br/>my $x :Trace = 42; # gets hound-magic applied<br/>my $y = $x; # inherits the hound-magic from $x<br/>my $z = $x + $y; # inherits a merge<br/><br/>print {$fh} $z; # can complain/fail if the value has incomplete history<br/><br/><br/>Some of this is achievable with objects and tie,<br/>but I found that limited (!) and tedious.<br/><br/>-- Ruud<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265173.html Thu, 01 Dec 2022 12:36:54 +0000 Re: Corinna design - field $name = EXPR or field $name {BLOCK} ? by Ovid On Tue, Nov 29, 2022 at 11:38 PM Paul &quot;LeoNerd&quot; Evans &lt;<br/>leonerd@leonerd.org.uk&gt; wrote:<br/><br/>&gt; class Thing { | class Thing {<br/>&gt; field $count :param //= 20; | ### No way to write this<br/>&gt; | ### using {BLOCK} notation<br/>&gt; } | }<br/>&gt;<br/>&gt; Thing-&gt;new( count =&gt; undef ); # 20 will still apply<br/>&gt;<br/><br/>As an aside, if we go with `=`, what about this?<br/><br/> field $foo :param ||= 1; # if $foo is false<br/> field $bar :param //= 2; # if $bar is undef<br/> field $baz :param ??= 3; # if $baz is missing<br/><br/>The latter example handles the pesky case where we *want* to allow undef to<br/>be valid, but we need a different default if the value is not passed to the<br/>constructor.<br/><br/>Curtis &quot;Ovid&quot; Poe<br/>CTO, All Around the World<br/>World-class software development and consulting<br/>https://allaroundtheworld.fr/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265172.html Thu, 01 Dec 2022 12:33:07 +0000 Re: Corinna design - field $name = EXPR or field $name {BLOCK} ? by Ovid On Wed, Nov 30, 2022 at 6:48 PM Paul &quot;LeoNerd&quot; Evans &lt;leonerd@leonerd.org.uk&gt;<br/>wrote:<br/><br/><br/>&gt; class AlarmTimer {<br/>&gt; field $duration = __CLASS__-&gt;_DEFAULT_DURATION;<br/>&gt; ...<br/>&gt; }<br/>&gt;<br/>&gt; class OneMinuteTimer :isa(AlarmTimer) {<br/>&gt; use constant _DEFAULT_DURATION =&gt; 60;<br/>&gt; }<br/>&gt;<br/>&gt; class FiveMinuteTimer :isa(AlarmTimer) {<br/>&gt; use constant _DEFAULT_DURATION =&gt; 60*5;<br/>&gt; }<br/>&gt;<br/>&gt; It also allows us to solve a bunch of other problems for which we had<br/>&gt; considered making a `$class` lexical visible inside methods. What if we<br/>&gt; just used __CLASS__ instead?<br/><br/><br/>I&#39;m a bit torn on this. While __CLASS__ is certainly interesting, I&#39;m<br/>unsure of the use case here.<br/><br/>I wrote a long email about this last night and deleted it because I<br/>realized my point was wrong. It&#39;s easy to get these things wrong,<br/>especially if we move too quickly (as I started to last night). You might<br/>recall the, uh, contentious discussions about class data on the #cor IRC<br/>channel. There were those who were *vehemently* opposed to Corinna offering<br/>any support for class data. Swear words were used. Obviously, I felt we<br/>need to support class data and methods, but while I didn&#39;t appreciate the<br/>swearing, I *do* appreciate the intent. I usually see class data being used<br/>incorrectly, so making it easier to do something incorrectly makes me<br/>concerned.<br/><br/>If a class is an expert about a &quot;thing,&quot; a subclass is a more specialized<br/>expert. You can have an &quot;Electrician&quot; class, and a subclass might be an<br/>&quot;Electrician::Residential&quot; who knows what the electrician knows, but is<br/>also aware of building codes. A subclass is there to provide specialized<br/>*behavior * and that specialized process might have specialized state<br/>associated with it. If all you&#39;re changing is the state and not the<br/>behavior, you have instance data.<br/><br/> my $five_minute_timer = Timer-&gt;new( duration =&gt; 60*5 );<br/><br/>With the above, we only need one class, not subclasses. I realize you<br/>already know this and were just throwing out quick examples to show the<br/>idea, but I would need to see a stronger use case for what you&#39;re<br/>proposing. Currently, I think the Corinna MMVP has everything we need to<br/>handle these cases.<br/><br/>For anyone who thinks this is just a theoretical concern, I recently<br/>completed a project with classes like this:<br/><br/> package SomeEndpoint {<br/> use base &#39;Endpoint::Base&#39;;<br/> sub route {&#39;/customer/orders&#39;}<br/> sub user_permissions {[&#39;order_read&#39;]}<br/> sub staff_permissions {[&#39;admin&#39;, &#39;order_read&#39;]}<br/> }<br/><br/>There were tons of these classes and one had to be created for every<br/>endpoint and the class had to be hard-coded in another package doing the<br/>routing. It made adding new endpoints painful and was bloating the code<br/>base.<br/><br/>If you look at the code, you realize you only need a single class because<br/>the &quot;class data&quot; should be instance data. The subclasses were *not* providing<br/>any specialized behavior. I replaced all of them with a single config file<br/>and by the time I was done, I had deleted over 60 classes (to be fair,<br/>that&#39;s the Reader&#39;s Digest version of the story). The developer who built<br/>the system is a good developer, but it&#39;s easy to get OOP code wrong.<br/><br/>Class data is sometimes necessary, but it should be used sparingly. It&#39;s<br/>bad if it&#39;s mutable because class data is basically global data<br/>(fortunately, Corinna can at least make this private to the class). The<br/>last time I can recall *needing* to use class data is for the<br/>aforementioned config file: reading and validating it on every request was<br/>expensive, so I wound up having to push that into a singleton (ugh) and<br/>*that* singleton was cached across requests (double-ugh). So class data can<br/>be a memory management tool, but when you&#39;re that far down the rabbit hole,<br/>it&#39;s more of an advanced technique. I&#39;m sure many of us have had to explain<br/>to junior programmers that they should stop obsessing about performance.<br/><br/>So that&#39;s my take. Creating __CLASS__ and making it easier for developers<br/>to do the wrong thing seems like a solution in search of a problem (sorry).<br/>Class methods are common and useful (any method which doesn&#39;t directly or<br/>indirectly access instance data should probably be a class method). But<br/>class *data* is often a code smell.<br/><br/>However, that&#39;s only in the context of your example. If you can provide a<br/>different example of a problem that&#39;s otherwise hard to solve, I&#39;d be happy<br/>to rethink my position.<br/><br/>Best,<br/>Curtis &quot;Ovid&quot; Poe<br/>CTO, All Around the World<br/>World-class software development and consulting<br/>https://allaroundtheworld.fr/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265171.html Thu, 01 Dec 2022 12:27:12 +0000 Re: Why is map BLOCK LIST slower than map EXPR, LIST by demerphq OhISee. Duh. I was timing $sum+=$_, which i guess is complex enough to<br/>trigger the difference. Leonerd was timing length($_). Can&#39;t compare<br/>apples and oranges. :-(<br/><br/>Dumbbench concurs that for length($_) there is practically no<br/>difference. 5.37 is a bit slower than 5.36, but inline with previous<br/>releases. Sorry for the confusion.<br/><br/>$ perlbrew exec --with<br/>perl-5.37.6,perl-5.36.0,perl-5.34.1,perl-5.32.1,perl-5.30.3,perl-5.28.3,perl-5.26.3,perl-5.24.4,perl-5.22.4,perl-5.20.3<br/>dumbbench -i 100 --code=&#39;map { length($_) } 1..500_000&#39; --code=&#39;map<br/>length($_), 1..500_000;&#39;<br/>perl-5.37.6<br/>==========<br/>code1: Ran 110 iterations (10 outliers).<br/>code1: Rounded run time per iteration (seconds): 7.0819e-02 +/- 3.3e-05 (0.0%)<br/>code2: Ran 120 iterations (20 outliers).<br/>code2: Rounded run time per iteration (seconds): 7.0907e-02 +/- 3.0e-05 (0.0%)<br/><br/>perl-5.36.0<br/>==========<br/>code1: Ran 105 iterations (5 outliers).<br/>code1: Rounded run time per iteration (seconds): 6.9505e-02 +/- 3.9e-05 (0.1%)<br/>code2: Ran 110 iterations (10 outliers).<br/>code2: Rounded run time per iteration (seconds): 6.9428e-02 +/- 2.1e-05 (0.0%)<br/><br/>perl-5.34.1<br/>==========<br/>code1: Ran 110 iterations (10 outliers).<br/>code1: Rounded run time per iteration (seconds): 6.9918e-02 +/- 2.6e-05 (0.0%)<br/>code2: Ran 115 iterations (12 outliers).<br/>code2: Rounded run time per iteration (seconds): 6.9787e-02 +/- 2.6e-05 (0.0%)<br/><br/>perl-5.32.1<br/>==========<br/>code1: Ran 110 iterations (10 outliers).<br/>code1: Rounded run time per iteration (seconds): 6.9653e-02 +/- 4.2e-05 (0.1%)<br/>code2: Ran 105 iterations (4 outliers).<br/>code2: Rounded run time per iteration (seconds): 6.9679e-02 +/- 3.6e-05 (0.1%)<br/><br/>perl-5.30.3<br/>==========<br/>code1: Ran 105 iterations (5 outliers).<br/>code1: Rounded run time per iteration (seconds): 7.4163e-02 +/- 4.4e-05 (0.1%)<br/>code2: Ran 105 iterations (5 outliers).<br/>code2: Rounded run time per iteration (seconds): 7.3635e-02 +/- 3.4e-05 (0.0%)<br/><br/>perl-5.28.3<br/>==========<br/>code1: Ran 105 iterations (1 outliers).<br/>code1: Rounded run time per iteration (seconds): 7.3501e-02 +/- 5.1e-05 (0.1%)<br/>code2: Ran 110 iterations (6 outliers).<br/>code2: Rounded run time per iteration (seconds): 7.3513e-02 +/- 3.4e-05 (0.0%)<br/><br/>perl-5.26.3<br/>==========<br/>code1: Ran 115 iterations (12 outliers).<br/>code1: Rounded run time per iteration (seconds): 7.4624e-02 +/- 4.0e-05 (0.1%)<br/>code2: Ran 120 iterations (19 outliers).<br/>code2: Rounded run time per iteration (seconds): 7.4700e-02 +/- 2.9e-05 (0.0%)<br/><br/>perl-5.24.4<br/>==========<br/>code1: Ran 110 iterations (9 outliers).<br/>code1: Rounded run time per iteration (seconds): 7.2078e-02 +/- 4.0e-05 (0.1%)<br/>code2: Ran 105 iterations (3 outliers).<br/>code2: Rounded run time per iteration (seconds): 7.1629e-02 +/- 2.9e-05 (0.0%)<br/><br/>perl-5.22.4<br/>==========<br/>code1: Ran 115 iterations (12 outliers).<br/>code1: Rounded run time per iteration (seconds): 7.5688e-02 +/- 1.9e-05 (0.0%)<br/>code2: Ran 105 iterations (3 outliers).<br/>code2: Rounded run time per iteration (seconds): 7.6097e-02 +/- 4.2e-05 (0.1%)<br/><br/>perl-5.20.3<br/>==========<br/>code1: Ran 110 iterations (6 outliers).<br/>code1: Rounded run time per iteration (seconds): 6.9619e-02 +/- 2.9e-05 (0.0%)<br/>code2: Ran 105 iterations (1 outliers).<br/>code2: Rounded run time per iteration (seconds): 6.9792e-02 +/- 3.3e-05 (0.0%)<br/><br/>On Thu, 1 Dec 2022 at 10:34, demerphq &lt;demerphq@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; On Wed, 30 Nov 2022 at 16:58, Dave Mitchell &lt;davem@iabyn.com&gt; wrote:<br/>&gt; &gt;<br/>&gt; &gt; On Tue, Nov 29, 2022 at 03:43:09PM +0000, Paul &quot;LeoNerd&quot; Evans wrote:<br/>&gt; &gt; &gt; But yet, very repeatably, the BLOCK version benchmarks slower than the<br/>&gt; &gt; &gt; EXPR one by at least a 10% margin.<br/>&gt; &gt;<br/>&gt; &gt; I think you are still measuring a form of noise.<br/>&gt; &gt;<br/>&gt; &gt; Take the following code (basically your original):<br/>&gt; &gt;<br/>&gt; &gt; use BetterBenchmark qw(cmpthese);<br/>&gt; &gt;<br/>&gt; &gt; my @x = 1..5_000_000;<br/>&gt; &gt; cmpthese( -3, {<br/>&gt; &gt; block =&gt; sub { map { length } @x },<br/>&gt; &gt; expr =&gt; sub { map length, @x }<br/>&gt; &gt; });<br/>&gt; &gt;<br/>&gt; &gt; when I run it several times on a non-threaded 5.36.0, I consistently see<br/>&gt; &gt; the block form is 6-19% slower.<br/>&gt; &gt;<br/>&gt; &gt; Now swap the anon sub definitions but keep the labels as is (so the labels<br/>&gt; &gt; are wrong):<br/>&gt; &gt;<br/>&gt; &gt; use BetterBenchmark qw(cmpthese);<br/>&gt; &gt;<br/>&gt; &gt; my @x = 1..5_000_000;<br/>&gt; &gt; cmpthese( -3, {<br/>&gt; &gt; block =&gt; sub { map length, @x },<br/>&gt; &gt; expr =&gt; sub { map { length } @x }<br/>&gt; &gt; });<br/>&gt; &gt;<br/>&gt; &gt; then I consistently see the expr form of map (the one labelled as block)<br/>&gt; &gt; around 6-22% slower. I.e. the slowness is something in the test setup<br/>&gt; &gt; and/or the vagaries of CPU cache alignment et al, not in the actual code.<br/>&gt;<br/>&gt; Well Dumbbench definitely doesn&#39;t measure noise, and it shows the<br/>&gt; variance of the timings and excludes outliers using standard<br/>&gt; statistical techniques. (Steffen Mueller wrote it, hes a physics guy).<br/>&gt;<br/>&gt; Reversing the code there still shows the BLOCK form measurably slower<br/>&gt; than the EXPR form.<br/>&gt;<br/>&gt; perlbrew exec --with<br/>&gt; perl-5.37.6,perl-5.36.0,perl-5.34.1,perl-5.32.1,perl-5.30.3,perl-5.28.3,perl-5.26.3,perl-5.24.4,perl-5.22.4,perl-5.20.3<br/>&gt; dumbbench -i 100 --code=&#39;map { $sum+=$_ } 1..500_000&#39; --code=&#39;map<br/>&gt; $sum+=$_, 1..500_000;&#39;<br/>&gt; perl-5.37.6<br/>&gt; ==========<br/>&gt; code1: Ran 110 iterations (9 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.0334e-02 +/- 5.1e-05 (0.1%)<br/>&gt; code2: Ran 110 iterations (10 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6238e-02 +/- 2.9e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.36.0<br/>&gt; ==========<br/>&gt; code1: Ran 110 iterations (9 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.1304e-02 +/- 5.1e-05 (0.1%)<br/>&gt; code2: Ran 115 iterations (12 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.7109e-02 +/- 5.6e-05 (0.2%)<br/>&gt;<br/>&gt; perl-5.34.1<br/>&gt; ==========<br/>&gt; code1: Ran 110 iterations (10 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.1543e-02 +/- 6.4e-05 (0.1%)<br/>&gt; code2: Ran 105 iterations (5 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6778e-02 +/- 4.6e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.32.1<br/>&gt; ==========<br/>&gt; code1: Ran 115 iterations (11 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.0471e-02 +/- 4.2e-05 (0.1%)<br/>&gt; code2: Ran 110 iterations (7 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6184e-02 +/- 4.5e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.30.3<br/>&gt; ==========<br/>&gt; code1: Ran 115 iterations (15 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.1391e-02 +/- 4.4e-05 (0.1%)<br/>&gt; code2: Ran 105 iterations (4 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6432e-02 +/- 3.8e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.28.3<br/>&gt; ==========<br/>&gt; code1: Ran 110 iterations (9 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.0962e-02 +/- 6.3e-05 (0.1%)<br/>&gt; code2: Ran 105 iterations (3 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6657e-02 +/- 6.5e-05 (0.2%)<br/>&gt;<br/>&gt; perl-5.26.3<br/>&gt; ==========<br/>&gt; code1: Ran 105 iterations (4 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.2305e-02 +/- 4.7e-05 (0.1%)<br/>&gt; code2: Ran 110 iterations (7 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.7420e-02 +/- 3.6e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.24.4<br/>&gt; ==========<br/>&gt; code1: Ran 110 iterations (8 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.1408e-02 +/- 2.9e-05 (0.1%)<br/>&gt; code2: Ran 110 iterations (6 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6683e-02 +/- 2.7e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.22.4<br/>&gt; ==========<br/>&gt; code1: Ran 110 iterations (8 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 6.0268e-02 +/- 4.0e-05 (0.1%)<br/>&gt; code2: Ran 105 iterations (4 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.8907e-02 +/- 4.1e-05 (0.1%)<br/>&gt;<br/>&gt; perl-5.20.3<br/>&gt; ==========<br/>&gt; code1: Ran 105 iterations (5 outliers).<br/>&gt; code1: Rounded run time per iteration (seconds): 5.0658e-02 +/- 5.3e-05 (0.1%)<br/>&gt; code2: Ran 105 iterations (3 outliers).<br/>&gt; code2: Rounded run time per iteration (seconds): 3.6224e-02 +/- 3.6e-05 (0.1%)<br/>&gt;<br/>&gt; I can&#39;t speak for Pauls Benchmark replacement, but Dumbbench is<br/>&gt; definitely NOT seeing a timing artifact.<br/>&gt;<br/>&gt; cheers,<br/>&gt; Yves<br/>&gt;<br/>&gt; --<br/>&gt; perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot;<br/><br/><br/><br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265170.html Thu, 01 Dec 2022 10:04:08 +0000 Re: Why is map BLOCK LIST slower than map EXPR, LIST by demerphq On Wed, 30 Nov 2022 at 16:58, Dave Mitchell &lt;davem@iabyn.com&gt; wrote:<br/>&gt;<br/>&gt; On Tue, Nov 29, 2022 at 03:43:09PM +0000, Paul &quot;LeoNerd&quot; Evans wrote:<br/>&gt; &gt; But yet, very repeatably, the BLOCK version benchmarks slower than the<br/>&gt; &gt; EXPR one by at least a 10% margin.<br/>&gt;<br/>&gt; I think you are still measuring a form of noise.<br/>&gt;<br/>&gt; Take the following code (basically your original):<br/>&gt;<br/>&gt; use BetterBenchmark qw(cmpthese);<br/>&gt;<br/>&gt; my @x = 1..5_000_000;<br/>&gt; cmpthese( -3, {<br/>&gt; block =&gt; sub { map { length } @x },<br/>&gt; expr =&gt; sub { map length, @x }<br/>&gt; });<br/>&gt;<br/>&gt; when I run it several times on a non-threaded 5.36.0, I consistently see<br/>&gt; the block form is 6-19% slower.<br/>&gt;<br/>&gt; Now swap the anon sub definitions but keep the labels as is (so the labels<br/>&gt; are wrong):<br/>&gt;<br/>&gt; use BetterBenchmark qw(cmpthese);<br/>&gt;<br/>&gt; my @x = 1..5_000_000;<br/>&gt; cmpthese( -3, {<br/>&gt; block =&gt; sub { map length, @x },<br/>&gt; expr =&gt; sub { map { length } @x }<br/>&gt; });<br/>&gt;<br/>&gt; then I consistently see the expr form of map (the one labelled as block)<br/>&gt; around 6-22% slower. I.e. the slowness is something in the test setup<br/>&gt; and/or the vagaries of CPU cache alignment et al, not in the actual code.<br/><br/>Well Dumbbench definitely doesn&#39;t measure noise, and it shows the<br/>variance of the timings and excludes outliers using standard<br/>statistical techniques. (Steffen Mueller wrote it, hes a physics guy).<br/><br/>Reversing the code there still shows the BLOCK form measurably slower<br/>than the EXPR form.<br/><br/>perlbrew exec --with<br/>perl-5.37.6,perl-5.36.0,perl-5.34.1,perl-5.32.1,perl-5.30.3,perl-5.28.3,perl-5.26.3,perl-5.24.4,perl-5.22.4,perl-5.20.3<br/>dumbbench -i 100 --code=&#39;map { $sum+=$_ } 1..500_000&#39; --code=&#39;map<br/>$sum+=$_, 1..500_000;&#39;<br/>perl-5.37.6<br/>==========<br/>code1: Ran 110 iterations (9 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.0334e-02 +/- 5.1e-05 (0.1%)<br/>code2: Ran 110 iterations (10 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6238e-02 +/- 2.9e-05 (0.1%)<br/><br/>perl-5.36.0<br/>==========<br/>code1: Ran 110 iterations (9 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.1304e-02 +/- 5.1e-05 (0.1%)<br/>code2: Ran 115 iterations (12 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.7109e-02 +/- 5.6e-05 (0.2%)<br/><br/>perl-5.34.1<br/>==========<br/>code1: Ran 110 iterations (10 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.1543e-02 +/- 6.4e-05 (0.1%)<br/>code2: Ran 105 iterations (5 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6778e-02 +/- 4.6e-05 (0.1%)<br/><br/>perl-5.32.1<br/>==========<br/>code1: Ran 115 iterations (11 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.0471e-02 +/- 4.2e-05 (0.1%)<br/>code2: Ran 110 iterations (7 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6184e-02 +/- 4.5e-05 (0.1%)<br/><br/>perl-5.30.3<br/>==========<br/>code1: Ran 115 iterations (15 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.1391e-02 +/- 4.4e-05 (0.1%)<br/>code2: Ran 105 iterations (4 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6432e-02 +/- 3.8e-05 (0.1%)<br/><br/>perl-5.28.3<br/>==========<br/>code1: Ran 110 iterations (9 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.0962e-02 +/- 6.3e-05 (0.1%)<br/>code2: Ran 105 iterations (3 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6657e-02 +/- 6.5e-05 (0.2%)<br/><br/>perl-5.26.3<br/>==========<br/>code1: Ran 105 iterations (4 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.2305e-02 +/- 4.7e-05 (0.1%)<br/>code2: Ran 110 iterations (7 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.7420e-02 +/- 3.6e-05 (0.1%)<br/><br/>perl-5.24.4<br/>==========<br/>code1: Ran 110 iterations (8 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.1408e-02 +/- 2.9e-05 (0.1%)<br/>code2: Ran 110 iterations (6 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6683e-02 +/- 2.7e-05 (0.1%)<br/><br/>perl-5.22.4<br/>==========<br/>code1: Ran 110 iterations (8 outliers).<br/>code1: Rounded run time per iteration (seconds): 6.0268e-02 +/- 4.0e-05 (0.1%)<br/>code2: Ran 105 iterations (4 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.8907e-02 +/- 4.1e-05 (0.1%)<br/><br/>perl-5.20.3<br/>==========<br/>code1: Ran 105 iterations (5 outliers).<br/>code1: Rounded run time per iteration (seconds): 5.0658e-02 +/- 5.3e-05 (0.1%)<br/>code2: Ran 105 iterations (3 outliers).<br/>code2: Rounded run time per iteration (seconds): 3.6224e-02 +/- 3.6e-05 (0.1%)<br/><br/>I can&#39;t speak for Pauls Benchmark replacement, but Dumbbench is<br/>definitely NOT seeing a timing artifact.<br/><br/>cheers,<br/>Yves<br/><br/>-- <br/>perl -Mre=debug -e &quot;/just|another|perl|hacker/&quot;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265169.html Thu, 01 Dec 2022 09:34:25 +0000 Re: Perl - nice to have features by Branislav Zahradník On Thu, 1 Dec 2022 at 04:11, Juerd Waalboer &lt;juerd@tnx.nl&gt; wrote: <br/> <br/>&gt; Branislav Zahradn&Atilde;&shy;k skribis 2022-11-28 12:17 (+0100): <br/>&gt; &gt;- support for thunk <br/>&gt; &gt;thunk will act like tie but will support only FETCH and will be executed <br/>&gt; only <br/>&gt; &gt;once (ie will replace value) <br/>&gt; <br/>&gt; I like this one. But I&#39;d prefer the following syntax: <br/>&gt; <br/>&gt; my $maybe_used { expensive_computation() } <br/>&gt; <br/>&gt; which would go well with the &quot;field VAR BLOCK&quot; syntax <br/>&gt; <br/> <br/>not bad idea. <br/> <br/>Though considering its expected usage, thunk will be used mostly anonymous <br/>- as return value or as function parameter, eg: <br/>return { foo =&gt; thunk, bar =&gt; thunk } <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265168.html Thu, 01 Dec 2022 06:02:07 +0000 Re: Perl - nice to have features by Juerd Waalboer Branislav Zahradn&iacute;k skribis 2022-11-28 12:17 (+0100):<br/>&gt;- support for thunk<br/>&gt;thunk will act like tie but will support only FETCH and will be executed only<br/>&gt;once (ie will replace value)<br/><br/>I like this one. But I&#39;d prefer the following syntax:<br/><br/> my $maybe_used { expensive_computation() }<br/><br/>which would go well with the &quot;field VAR BLOCK&quot; syntax, if that gets chosen, especially if both the assignment and block syntax get implemented, with the semantic difference as suggested in my previous message to this list, &quot;Re: Corinna design - field $name = EXPR or field $name {BLOCK} ?&quot;, Message-ID: &lt;Y4gVDc08B2fdCevD@k&gt;.<br/>-- <br/>Met vriendelijke groet, // Kind regards, // Korajn salutojn,<br/><br/>Juerd Waalboer &lt;juerd@tnx.nl&gt;<br/>TNX<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265167.html Thu, 01 Dec 2022 03:11:45 +0000 Re: Corinna design - field $name = EXPR or field $name {BLOCK} ? by Juerd Waalboer Paul &quot;LeoNerd&quot; Evans skribis 2022-11-29 22:38 (+0000):<br/>&gt;TL;DR: Porters - please help me pick what some syntax should look like<br/><br/>Thanks for the very clear layout of the pros and cons with side-by-side comparisons. I enjoyed reading it, and am glad my email setup uses a monospaced font :)<br/><br/>The problem is presented as a single functionality with two different syntaxes for it, and the dichotomy between those two syntaxes. But I wonder if it has been considered that if these two syntaxes each remind of different semantics by the way they resemble existing syntax, maybe that means that there could be room for both semantics?<br/><br/>&gt;Conversely, block notation makes it much more obvious that the<br/>&gt;expression doesn&#39;t happen just once at class-definition time, but<br/>&gt;happens every time within the constructor of each instance.<br/><br/>What if block notation would indeed make it be evaluated every time within the constructor of each instance, BUT assignment notation would do what it looks like: evaluate just once at class-definition time.<br/><br/>What if indeed<br/><br/> my $next_id = 1;<br/> field $id = $next_id++;<br/><br/>would evaluate that just once - that is: every instance of the class get the same $id = 1 default, and $next_id if not touched elsewhere remains at 2. Not useful in this specific example, but it would do exactly what other assignments do:<br/><br/> my $next_id = 1;<br/> my $id = $next_id++;<br/><br/>To get evaluation at construction time, you&#39;d use the BLOCK syntax.<br/><br/>&gt;It feels a bit more like a `method` block in this case, where<br/>&gt;the same thing happens with a spontaneous `$self`.<br/><br/>If it feels like a method block, why not solve the &quot;can&#39;t do //= with BLOCK&quot; by making use of how it looks like a method, and allowing a unary positional signature, which if provided forces the BLOCK to be evaluated even in the case of a provided value?<br/><br/> field $count($param) { $param // 20 }<br/><br/>or even<br/><br/> field $count($param //= 20) { $param }<br/><br/>since that should then of course both work.<br/><br/>This would be distinct from the simple `field $count { 20 }` which would not override an explicit undef.<br/><br/>Or maybe just an attribute, :override_undef, if deciding from the arity is too implicit.<br/><br/>&gt;Can anyone see a way out of this quandry?<br/><br/>The usual: why not both? :)<br/><br/>By making assignment behave more like assignment and making the block behave more like a method, I think there&#39;s a stronger sense of &quot;similar things should look similar&quot;. Whoever feels like they need consistent syntax, can always just use the BLOCK syntax for everything. But the assignment version would be available for the simplest cases, which I think will cover most uses anyway.<br/>-- <br/>Met vriendelijke groet, // Kind regards, // Korajn salutojn,<br/><br/>Juerd Waalboer &lt;juerd@tnx.nl&gt;<br/>TNX<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/12/msg265166.html Thu, 01 Dec 2022 02:45:13 +0000 Re: Corinna design - field $name = EXPR or field $name {BLOCK} ? by Paul "LeoNerd" Evans On Wed, 30 Nov 2022 14:33:33 +0100<br/>Ovid &lt;curtis.poe@gmail.com&gt; wrote:<br/><br/>&gt; I&#39;m not yet sure of the right way to go, but while I originally liked<br/>&gt; the idea of injecting $self into the default block, I think I was<br/>&gt; wrong. Here&#39;s a simplistic example:<br/>&gt; <br/>&gt; field $foo;<br/>&gt; field $bar { $self-&gt;_init_bar };<br/>&gt; field $baz;<br/>&gt; <br/>&gt; Fields are initialized in the order declared (with :common fields<br/>&gt; having priority, of course), but in calling _init_bar, we don&#39;t yet<br/>&gt; know what that&#39;s relying on. What if it&#39;s this?<br/>&gt; <br/>&gt; method _init_bar () {<br/>&gt; return $baz + 1;<br/>&gt; }<br/>...<br/><br/>So, I _was_ going to write a long and interesting defence of &quot;but we<br/>want subclassing dispatch to override defaults in subclasses&quot;, but then<br/>a thought occurred to me.<br/><br/>In almost all the cases I would use this, I don&#39;t actually care about<br/>dispatch on an instance (i.e. $self), all I care about is what the<br/>actual runtime class is; i.e. ref($self), or the $class of the<br/>constructor.<br/><br/>On further thought then, I wonder if we could solve both this problem<br/>and the &quot;lexicals spontaneously appear&quot; problem at once, by introducing<br/>a new token, __CLASS__.<br/><br/>The idea would be that __CLASS__ inside a method (or field initialiser<br/>expression/block) yields the actual dynamic class of the instance or<br/>constructor. ((i.e. It&#39;s not just the same as the static compile-time<br/>package name given by __PACKAGE__)). This would allow one to write:<br/><br/> class AlarmTimer {<br/> field $duration = __CLASS__-&gt;_DEFAULT_DURATION;<br/> ...<br/> }<br/><br/> class OneMinuteTimer :isa(AlarmTimer) {<br/> use constant _DEFAULT_DURATION =&gt; 60;<br/> }<br/><br/> class FiveMinuteTimer :isa(AlarmTimer) {<br/> use constant _DEFAULT_DURATION =&gt; 60*5;<br/> }<br/><br/>It also allows us to solve a bunch of other problems for which we had<br/>considered making a `$class` lexical visible inside methods. What if we<br/>just used __CLASS__ instead?<br/><br/><br/>Now some folks might object to the spelling of __CLASS__ because it<br/>doesn&#39;t behave as a compiletime-constant (as __PACKAGE__, __FILE__ and<br/>__LINE__ all do); but then neither does __SUB__ when inside an<br/>anonymous closure. And __DATA__ and __END__ are verymuch &quot;weird parser<br/>tokens&quot; and not just placeholders for constants anyway, so I think that<br/>argument is rather lost.<br/><br/>I think __CLASS__ feels like a good step forward, and I&#39;m going to test<br/>it out in Object::Pad and see what we think of it there.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2022/11/msg265165.html Wed, 30 Nov 2022 17:48:46 +0000