Mailing List Archive

now in blead: n-at-a-time foreach
Porters,

I have merged #18925 <https://github.com/Perl/perl5/pull/18925>, which adds n-at-a-time iteration to perl. Thanks to Damian Conway for the original suggestion of the syntax we used, Nicholas Clark for the implementation, and Tony Cook and Matthew Horsfall and others for code review.

for my ($k, $v) (%hash) {
say "The value for $k is $v";
}

Enjoy!

--
rjbs
Re: now in blead: n-at-a-time foreach [ In reply to ]
Great news, thanks!

On Fri, Oct 15, 2021 at 6:18 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> Porters,
>
> I have merged #18925 <https://github.com/Perl/perl5/pull/18925>, which
> adds n-at-a-time iteration to perl. Thanks to Damian Conway for the
> original suggestion of the syntax we used, Nicholas Clark for the
> implementation, and Tony Cook and Matthew Horsfall and others for code
> review.
>
> for my ($k, $v) (%hash) {
> say "The value for $k is $v";
> }
>
>
> Enjoy!
>
> --
> rjbs
>
Re: now in blead: n-at-a-time foreach [ In reply to ]
On Fri, 15 Oct 2021 10:17:12 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> Porters,
>
> I have merged #18925 <https://github.com/Perl/perl5/pull/18925>,
> which adds n-at-a-time iteration to perl. Thanks to Damian Conway
> for the original suggestion of the syntax we used, Nicholas Clark for
> the implementation, and Tony Cook and Matthew Horsfall and others for
> code review.
>
> for my ($k, $v) (%hash) {
> say "The value for $k is $v";
> }

(as discussed on PSC call):

I shall follow this up with a pre-RFC suggestion for a `kv` builtin
(name still to be bikeshodden) which would do "the obvious" thing on
lists/arrays, to allow the following:

for my ($idx, $val) (kv @elements) {
# $idx=0, $val=$elements[0],
# $idx=1, $val=$elements[1],
# ...
}

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: now in blead: n-at-a-time foreach [ In reply to ]
On Fri, 15 Oct 2021 15:26:50 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> (as discussed on PSC call):
>
> I shall follow this up with a pre-RFC suggestion for a `kv` builtin
> (name still to be bikeshodden) which would do "the obvious" thing on
> lists/arrays, to allow the following:
>
> for my ($idx, $val) (kv @elements) {
> # $idx=0, $val=$elements[0],
> # $idx=1, $val=$elements[1],
> # ...
> }

This very similar to %elements[*] from everything-slices RFC:
https://github.com/Perl/RFCs/blob/master/rfcs/rfc0005.md
Re: now in blead: n-at-a-time foreach [ In reply to ]
* Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-10-15 15:26:50 +0100]:

> On Fri, 15 Oct 2021 10:17:12 -0400
> "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
>
> > Porters,
> >
> > I have merged #18925 <https://github.com/Perl/perl5/pull/18925>,
> > which adds n-at-a-time iteration to perl. Thanks to Damian Conway
> > for the original suggestion of the syntax we used, Nicholas Clark for
> > the implementation, and Tony Cook and Matthew Horsfall and others for
> > code review.
> >
> > for my ($k, $v) (%hash) {
> > say "The value for $k is $v";
> > }

I read the RFC and I see this is the implementation of a non-destructive
and actually working kind of "each". Correct?

More generally, I think that calling it "n-at-a-time" and not showing an
example of this should be corrected. If I read things correctly, grabbing
(e.g.) 3 things at a time from a list would look like:

for my ($first, $second, $third) (@items) {
#.. do something with each batch of 3 items
}

Question, if the "n" in "n-things-at-a-time" doesn't divide perfectly
into the total number of items in "@items", does that mean that the scalars
which prove to be unused on the last interation are 'undef'?

>
> (as discussed on PSC call):
>
> I shall follow this up with a pre-RFC suggestion for a `kv` builtin
> (name still to be bikeshodden) which would do "the obvious" thing on
> lists/arrays, to allow the following:
>
> for my ($idx, $val) (kv @elements) {
> # $idx=0, $val=$elements[0],
> # $idx=1, $val=$elements[1],
> # ...
> }

..except indexs in arrays are implicit and keys in hashes are not; are
you suggesting that "kv" (keyvalue) returns an index as the "key" for
arrays (which are not members of the list) and "the obvious" thing for
hashes where the key is part of the list?

Not to bikeshed; seems "kv" (a fine name if you ask me) should always return
the next "tuple" (size 2) of elements be the list come from a hash or array.

If you wanted to do something with implicit indices, that'd be a totally
different call and should also work the same on arrays as it does on hashes-
i.e., have no concept of "key/value" tuples - only elements and their actual
index.

So can you clarify what you mean and how the above example (which has the
problem I outlined in how you seem to be schizophrenicly conflating arrays
and hashes) - and how this relates to "n things at a time" (which does
make sense as the basis for a "better `each`")?

Cheers,
Brett
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: now in blead: n-at-a-time foreach [ In reply to ]
On Fri, Oct 15, 2021 at 11:30 AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

>
> Question, if the "n" in "n-things-at-a-time" doesn't divide perfectly
> into the total number of items in "@items", does that mean that the scalars
> which prove to be unused on the last interation are 'undef'?
>

Yes, the RFC specifies this.

>
> > (as discussed on PSC call):
> >
> > I shall follow this up with a pre-RFC suggestion for a `kv` builtin
> > (name still to be bikeshodden) which would do "the obvious" thing on
> > lists/arrays, to allow the following:
> >
> > for my ($idx, $val) (kv @elements) {
> > # $idx=0, $val=$elements[0],
> > # $idx=1, $val=$elements[1],
> > # ...
> > }
>
> ..except indexs in arrays are implicit and keys in hashes are not; are
> you suggesting that "kv" (keyvalue) returns an index as the "key" for
> arrays (which are not members of the list) and "the obvious" thing for
> hashes where the key is part of the list?
>
> Not to bikeshed; seems "kv" (a fine name if you ask me) should always
> return
> the next "tuple" (size 2) of elements be the list come from a hash or
> array.
>
> If you wanted to do something with implicit indices, that'd be a totally
> different call and should also work the same on arrays as it does on
> hashes-
> i.e., have no concept of "key/value" tuples - only elements and their
> actual
> index.
>
> So can you clarify what you mean and how the above example (which has the
> problem I outlined in how you seem to be schizophrenicly conflating arrays
> and hashes) - and how this relates to "n things at a time" (which does
> make sense as the basis for a "better `each`")?
>

Key-value slices on arrays are already a thing and behave this way (keys
are indexes). As do the keys() and values() builtins.

-Dan