develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
Nicholas Clark
June 9, 2021 06:58
Re: RFC: Multiple-alias syntax for for
Message ID:
On Tue, Jun 08, 2021 at 07:09:20PM +0100, Philip R Brenan wrote:
> Cicero:  The sinews of Perl are an infinite supply of CPAN.
> CPAN contains many variants on this theme as shown in the example below.
> Please tell me how this proposal would improve upon them well enough to
> justify the immense effort of implementing this new feature in the core of
> Perl?

"immense effort"

Down in the part that everyone quoted, but didn't seem to read:

> > > # Prototype Implementation
> > >
> > > "Here's one I made earlier" applies - we already have one written, so
> > there's no need to duplicate work

I believe that it took me about 3 days to implement this.

By the standards of what it would take to implement some of the language
changes I've seen proposed, that is trivial.

Moreover, it's relatively self contained, so relatively low risk.

Runtime changes are in one function in one file:

$ git diff -w --stat fd11779cdb4d6f04f5f869d890845a060b696bba pp_hot.c
 1 file changed, 80 insertions(+), 19 deletions(-)

optree generation changes are small:

$ git diff -w --stat fd11779cdb4d6f04f5f869d890845a060b696bba op.c
 1 file changed, 62 insertions(+), 4 deletions(-)

Grammar changes are small:

$ git diff  --stat fd11779cdb4d6f04f5f869d890845a060b696bba perly.y
 1 file changed, 20 insertions(+), 1 deletion(-)

One doesn't *need* sufficient knowledge to implement changes to be able to
discuss whether the trade offs are worth it, but one does need a good
*feel* for what is hard/what is not, before passing judgement on the
risk/reward of an idea. I didn't set off knowing that it would be exactly
this small, but I had an idea that likely it would be, because I knew
what shape the runtime code for `for` has (and it's not very large.)

As to your suggestion:

> sub forEachKeyValue(&%)
>     # Iterate over a hash for each key and value
>  {my ($body, %hash) = @_;
>     # Body to be executed, hash to be iterated
>   &$body($_, $hash{$_}) for sort keys %hash;
>  }
> my %h = (a=>1, b=>2, c=>3);
> my @t;
> forEachKeyValue
>  {my ($letter, $number) = @_;
>   push @t,  "Letter=$letter, number=$number";
>  } %h;

Right now, if I need to iterate over key and value combined, I'm tempted
to write:

for my $k (keys %hash) {
   my $v = $hash{$h};

That's a lot fewer lines than your suggestion, and doesn't *copy* the entire
hash, avoids a lot of function calls, and I can choose whether I want to
sort or not.

Yes, it works.

But it doesn't generalise to n-at-a-time iteration over arbitrary lists (or
arrays), which the proposed syntax does.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About