Mailing List Archive

On Tue, Jun 15, 2021 at 6:13 AM Tony Cook <tony@develop-help.com> wrote:

> On Mon, Jun 14, 2021 at 09:22:10AM +0000, Nicholas Clark wrote:
> > 2) Should it issue an experimental warning?
>
> I think it should at least have an experimental warning, mostly as a
> "coders haven't beating on the implementation for N years, there might
> be bugs" warning.
>
> Chained comparisons didn't get such a warning, and that had one
> serious bug that I'm aware of (constant folding could underflow the
> stack.)
>

I kind of think we need to have a (separate) discussion on when and
especially why we have experimental warnings.

Leon

Branislav Zahradník <happy.barney@gmail.com> writes:

> On Mon, 14 Jun 2021 at 17:28, Dan Book <grinnz@gmail.com> wrote:
>
>> On Mon, Jun 14, 2021 at 5:23 AM Nicholas Clark <nick@ccl4.org> wrote:
>>
>>> There are 4 open issues that I can see, that I'm not sure about:
>>>
>>> 1) Should this be behind a feature guard?
>>>
>>
>> Since the current proposed syntax has no conflicts, I don't think this is
>> needed.
>>
>
> Wrong
>
> It has conflicts, with every perl before one implementing it.
> Therefore it should required at least bundle specification

Of course it doesn't work on older perls that don't support the feature,
that's not what we mean by "conflict". We mean that it doesn't conflict
with (and change the meaning of) existing valid syntax.

The point of feature.pm is to be able to opt-in to behaviour or syntax
that might change the meaning of existing programs.

Ths feature does not change the behaviour of existing programs, so no
feature flag is needed. It should still have an experimental-category
warning, though.

- ilmari

On Tue, 15 Jun 2021 at 12:09, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
wrote:

>
> Of course it doesn't work on older perls that don't support the feature,
> that's not what we mean by "conflict". We mean that it doesn't conflict
> with (and change the meaning of) existing valid syntax.
>
> The point of feature.pm is to be able to opt-in to behaviour or syntax
> that might change the meaning of existing programs.
>
> Ths feature does not change the behaviour of existing programs, so no
> feature flag is needed. It should still have an experimental-category
> warning, though.
>
> - ilmari
>

Be polite to your customers.

Allowing new syntax only with "use v5.xx" guard prevents situation when
your code
starts to break after OS upgrade (downgrade) on syntax error.

Hiding new syntax behind new guard says to managers (if they are listen to
they programmers)
hey, perl is not dead, there is new version, we should upgrade ... (ideally
without refactoring)

So imho message:
this is perl 5,8, you need at least 5.99 is better then "syntax error at"

On Tue, 15 Jun 2021 13:18:29 +0200
Branislav Zahradník <happy.barney@gmail.com> wrote:

> Allowing new syntax only with "use v5.xx" guard prevents situation
> when your code
> starts to break after OS upgrade (downgrade) on syntax error.
>
> Hiding new syntax behind new guard says to managers (if they are
> listen to they programmers)
> hey, perl is not dead, there is new version, we should upgrade ...
> (ideally without refactoring)

We didn't do that with // or ->@*


$ perl5.8.9 -e 'print undef // 123'
Warning: Use of "undef" without parentheses is ambiguous at -e line 1.
Number found where operator expected at -e line 1, near "// 123"
(Missing operator before 123?)
syntax error at -e line 1, near "// 123"
Execution of -e aborted due to compilation errors.

$ perl5.10.1 -e 'print undef // 123'
123


$ perl5.22.2 -E 'say [1,2,3]->@*'
Array found where operator expected at -e line 1, near "->@*"
(Missing operator before @*?)
syntax error at -e line 1, near "->@*
"
Execution of -e aborted due to compilation errors.

$ perl5.24.4 -E 'say [1,2,3]->@*'
123



--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Tue, Jun 15, 2021, at 12:13 AM, Tony Cook wrote:
> On Mon, Jun 14, 2021 at 09:22:10AM +0000, Nicholas Clark wrote:
> > 2) Should it issue an experimental warning?
>
> I think it should at least have an experimental warning, mostly as a
> "coders haven't beating on the implementation for N years, there might
> be bugs" warning.

I think this could be marked experimental in v5.36 and, most likely, not experimental in v5.38. It would be okay, and I wouldn't object.

That said, I'll point out that "experimental" warnings are there because they might *change*, and not because they might have bugs. I don't believe we're likely to make incompatible changes with the syntax proposed, but I also think that one experimental version is a reasonable position to take. In general, though, I'd rather we just say "This feature is new and while we've tested it enough to feel good, it may have bugs not caught until it gets executed a few billion times."

--
rjbs

On Tue, Jun 08, 2021 at 11:20:57AM +0000, Nicholas Clark wrote:
> About two months ago Rik had mentioned to me the idea of implementing this
> (currently illegal) syntax to iterate over hashes:
>
> for my ($key, $value) (%hash) { ... }
>
> which isn't actually hash specific - it generalises to N-at-a-time over any
> list.

Just throwing this out as a possible further/later extension of this idea:
allow for multiple lists, separated by semicolons, to be iterated over in
parallel, to provide a more general N-from-M iteration mechanism.

This could already be done by using a List::Util::zip() type function,
but this way would be built-in so more efficient, and doesn't involve
creating a temporary list.

So given:

@a = (1,2,3,4,5); @b = (11,22,33,44,55); @c = (111,222,333,444,555);

consider

for my ($x, $y, $z) (@a; @b; @c) { print "($x,$y,$z) " }
# outputs (1,11,111) (2,22,222) ... (5,55,555)

and

for my $x (@a; @b; @c) { print "$x " }
# outputs 1 11 111 2 22 222 ... 5 55 555

and

for my ($x, $y) (@a; @b; @c) { print "($x,$y) " }
# outputs (1,11) (111,2) (22,222) ... (5,55) (555,<undef>)

and

# just to make clear that it's 3 lists, not 3 arrays;
for my $x ((7,@a); (8,@b); (9,@c)) { print "$x " }
# outputs 7 8 9 1 11 111 2 22 222 ... 5 55 555

Obviously it would do suitable injecting of undef final values for differing
list lengths etc.

This doesn't clash with the existing

for (init; cond; iterate) { ...}

syntax, since that doesn't have an iterator variable.

Anyway, I'm not particularly championing this suggestion; just mentioning
in passing as I process through my backlog of several month's unread
p5p/github emails.


--
This is a great day for France!
-- Nixon at Charles De Gaulle's funeral

On Tue, 22 Jun 2021 at 17:04, Dave Mitchell <davem@iabyn.com> wrote:

> On Tue, Jun 08, 2021 at 11:20:57AM +0000, Nicholas Clark wrote:
>
> So given:
>
> @a = (1,2,3,4,5); @b = (11,22,33,44,55); @c = (111,222,333,444,555);
>
> consider
>
> for my ($x, $y, $z) (@a; @b; @c) { print "($x,$y,$z) " }
> # outputs (1,11,111) (2,22,222) ... (5,55,555)
>
>
>
You can expand this idea with loop similar to Java for-each loops
and/or mix multi-alias iterators (using colon as iterator bind operator,
just to provide some kind of example)
for my ($x, $y1, $y2, $z1, $z2) ($x : (8, @a); ($y1, $y2) : %b; ($z1, $z2)
: @c)

Don't recall seeing this case discussed:

my @iters = (undef,undef); # empty list would be run-time
error!
for @iters ( @iterees) {
... # $iters[0] is alias to even iterees, $iters[1]
is alias to odd ones
# if @iters changes size, next time through it gets
that many
}




--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

On Tue, Jun 22, 2021, at 2:07 PM, David Nicol wrote:
>
> Don't recall seeing this case discussed:
>
> my @iters = (undef,undef); # empty list would be run-time error!
> for @iters ( @iterees) {
> ... # $iters[0] is alias to even iterees, $iters[1] is alias to odd ones
> # if @iters changes size, next time through it gets that many
> }

It's not legal. The thing after "for" must be a parenthesized list of scalar targets.

--
rjbs

On 6/22/21 2:58 PM, Ricardo Signes wrote:
> On Tue, Jun 22, 2021, at 2:07 PM, David Nicol wrote:
>>
>> Don't recall seeing this case discussed:
>>
>>               my @iters = (undef,undef); # empty list would be
>> run-time error!
>>               for @iters ( @iterees) {
>>                     ... #   $iters[0] is alias to even iterees,
>> $iters[1] is alias to odd ones
>>                     # if @iters changes size, next time through it
>> gets that many
>>              }
>
> It's not legal.  The thing after "for" must be a parenthesized list of
> scalar targets.
>

but an easy workaround is this (my guess):

for ( $iters[0], $iters[1] ) ( @iterees) {

or even with the expansion??:

for ( @iters[*] ) ( @iterees) {

uri

On Tue, Jun 22, 2021 at 04:03:39PM +0100, Dave Mitchell wrote:

> Just throwing this out as a possible further/later extension of this idea:
> allow for multiple lists, separated by semicolons, to be iterated over in
> parallel, to provide a more general N-from-M iteration mechanism.

It's an interesting idea, but you can't implement it with the existing OPs.
So it would belong in its own RFC, and given that it's likely tricky to
implement, and neither you nor me are interested in implementing it, I
don't think that it would go anywhere soon.

(This isn't a "no, we must never do this" - its "I don't see much benefit
in discussing it further until it looks likely that someone would write it
in a timely fashion" combined with "and if a person with the skills and time
existed, there are other improvements that gain Perl more")

> and
>
> for my ($x, $y) (@a; @b; @c) { print "($x,$y) " }
> # outputs (1,11) (111,2) (22,222) ... (5,55) (555,<undef>)
>
> and
>
> # just to make clear that it's 3 lists, not 3 arrays;
> for my $x ((7,@a); (8,@b); (9,@c)) { print "$x " }
> # outputs 7 8 9 1 11 111 2 22 222 ... 5 55 555

Implementation wise (as you know, but most folks might not), there's
an optimisation to avoid creating a temporary list for iterating whole
arrays. So logically the first example you give ought to avoid creating
3 temporary lists, or it could get slow. Whereas the second can not.

So there's quite a lot of state and complexity needed already.

> This doesn't clash with the existing
>
> for (init; cond; iterate) { ...}
>
> syntax, since that doesn't have an iterator variable.

That's an interesting observation.

Nicholas Clark

On Tue, Jun 22, 2021 at 03:04:31PM -0400, Uri Guttman wrote:
> On 6/22/21 2:58 PM, Ricardo Signes wrote:
> > On Tue, Jun 22, 2021, at 2:07 PM, David Nicol wrote:
> > >
> > > Don't recall seeing this case discussed:
> > >
> > > ? ? ? ? ? ? ? my?@iters = (undef,undef); # empty list would be
> > > run-time error!
> > > ? ? ? ? ? ? ? for?@iters (?@iterees) {
> > > ? ? ? ? ? ? ? ? ? ? ... #? ?$iters[0] is alias to even iterees,
> > > $iters[1] is alias to odd ones
> > > ? ? ? ? ? ? ? ? ? ? # if?@iters changes size, next time through it
> > > gets that many
> > > ? ? ? ? ? ? ?}
> >
> > It's not legal.? The thing after "for" must be a parenthesized list of
> > scalar targets.
> >
>
> but an easy workaround is this (my guess):
>
> for ( $iters[0], $iters[1] ) (?@iterees) {
>
> or even with the expansion??:
>
> for ( @iters[*] ) (?@iterees) {

None of this is easy to add to the current implementation of 1-at-a-time
foreach loops.

I'm not convinced that it's a good idea making the step size of the iteration
be dependant on the array's current size, as this feels like
action-at-a-distance.

The target(s) of a foreach loop is an alias, not an assignment - to be
consistent with this:

$ perl -E 'my $foo = "Hello"; for $foo ("Boo!") { say $foo; say \$foo } say $foo; say \$foo'
Boo!
SCALAR(0x559598381f38)
Hello
SCALAR(0x5595983721b0)

it's unclear whether the the existing *values* of the array would be what
was aliased, or the entire array.

I don't think that this discussion is heading in any direction that can
be implemented.

Nicholas Clark

On Tue, Jun 15, 2021 at 02:59:32PM -0400, Ricardo Signes wrote:
> On Tue, Jun 15, 2021, at 12:13 AM, Tony Cook wrote:
> > On Mon, Jun 14, 2021 at 09:22:10AM +0000, Nicholas Clark wrote:
> > > 2) Should it issue an experimental warning?
> >
> > I think it should at least have an experimental warning, mostly as a
> > "coders haven't beating on the implementation for N years, there might
> > be bugs" warning.
>
> I think this could be marked experimental in v5.36 and, most likely, not experimental in v5.38. It would be okay, and I wouldn't object.

So, this is catch-up from what we discussed on Friday...

Consensus seemed to be that

1) we didn't need a feature guard
2) we should have an experimental warning

which effectively has resolved the open issues.
So the (outgoing) PSC felt that we could make this state transition:

Provisional RFC
"we think this idea is worth implementing"
(We have a firm idea of what we want to do)
|
v
Accepted RFC
"we think this plan looks viable"
(There is a sane plan for how to do it)

and I have updated the RFC with all of this, and the status tables at
https://github.com/Perl/RFCs


At which point "time passes" and once I have an implementation that I
believe implements the RFC, I open a PR with it.


So, time passes...

https://github.com/Perl/perl5/pull/18925

and it's regular code review time.


I guess the reviewers ask

* does it implement what the RFC specified?

in addition to the usual

* does the code have bugs or other defects?
* on balance, does merging this give a net improvement?


(and the trial process says this is a code review decision, not a PSC
decision)

Nicholas Clark

The Chapel language has some interesting concepts implemented, and they all have to do with exactly what I meant in my YAPC::Zoom::2021 talk; the lanaguage has no inherent constraints on these kind of concurrent semantics. I claim this is a good thing, it just needs to be recognized and expressed clearly - particularly as it relates to the perl uniprocess.

I say that because this topic reminds me of this, as does pre-RFC for extending hash slices in an expressive way.

Since we're all students of the esoteric, here's a link to Chapel's documentation.

https://chapel-lang.org/docs/language/spec/ranges.html

I highly recommend these specs be studied. It might clarify some ideas and give genesis to new ones.

Cheers,
Brett

??????? Original Message ???????

On Wednesday, June 23rd, 2021 at 2:11 AM, Nicholas Clark <nick@ccl4.org> wrote:

> On Tue, Jun 22, 2021 at 03:04:31PM -0400, Uri Guttman wrote:
>
> > On 6/22/21 2:58 PM, Ricardo Signes wrote:
> >
> > > On Tue, Jun 22, 2021, at 2:07 PM, David Nicol wrote:
> > >
> > > > Don't recall seeing this case discussed:
> > > >
> > > > my @iters = (undef,undef); # empty list would be
> > > >
> > > > run-time error!
> > > >
> > > >               for @iters ( @iterees) {
> > > >
> > > >                     ... #   $iters[0] is alias to even iterees,
> > > >
> > > > $iters[1] is alias to odd ones
> > > >
> > > >                     # if @iters changes size, next time through it
> > > >
> > > > gets that many
> > > >
> > > >              }
> > >
> > > It's not legal.  The thing after "for" must be a parenthesized list of
> > >
> > > scalar targets.
> >
> > but an easy workaround is this (my guess):
> >
> > for ( $iters[0], $iters[1] ) ( @iterees) {
> >
> > or even with the expansion??:
> >
> > for ( @iters[*] ) ( @iterees) {
>
> None of this is easy to add to the current implementation of 1-at-a-time
>
> foreach loops.
>
> I'm not convinced that it's a good idea making the step size of the iteration
>
> be dependant on the array's current size, as this feels like
>
> action-at-a-distance.
>
> The target(s) of a foreach loop is an alias, not an assignment - to be
>
> consistent with this:
>
> $ perl -E 'my $foo = "Hello"; for $foo ("Boo!") { say $foo; say \$foo } say $foo; say \$foo'
>
> Boo!
>
> SCALAR(0x559598381f38)
>
> Hello
>
> SCALAR(0x5595983721b0)
>
> it's unclear whether the the existing values of the array would be what
>
> was aliased, or the entire array.
>
> I don't think that this discussion is heading in any direction that can
>
> be implemented.
>
> Nicholas Clark

I probably should have poked around more before sending this last email, but here's the actual spec:

https://chapel-lang.org/docs/language/spec/index.html

Probably of note is this, which defines it's OOP pretty clearly, I think. There are probably not a lot of surprises, but it still seems like a good skim.

https://chapel-lang.org/docs/language/spec/classes.html

Brett

??????? Original Message ???????

On Wednesday, June 23rd, 2021 at 3:33 PM, mah.kitteh via perl5-porters <perl5-porters@perl.org> wrote:

> The Chapel language has some interesting concepts implemented, and they all have to do with exactly what I meant in my YAPC::Zoom::2021 talk; the lanaguage has no inherent constraints on these kind of concurrent semantics. I claim this is a good thing, it just needs to be recognized and expressed clearly - particularly as it relates to the perl uniprocess.
>
> I say that because this topic reminds me of this, as does pre-RFC for extending hash slices in an expressive way.
>
> Since we're all students of the esoteric, here's a link to Chapel's documentation.
>
> https://chapel-lang.org/docs/language/spec/ranges.html
>
> I highly recommend these specs be studied. It might clarify some ideas and give genesis to new ones.
>
> Cheers,
>
> Brett
>
> ??????? Original Message ???????
>
> On Wednesday, June 23rd, 2021 at 2:11 AM, Nicholas Clark nick@ccl4.org wrote:
>
> > On Tue, Jun 22, 2021 at 03:04:31PM -0400, Uri Guttman wrote:
> >
> > > On 6/22/21 2:58 PM, Ricardo Signes wrote:
> > >
> > > > On Tue, Jun 22, 2021, at 2:07 PM, David Nicol wrote:
> > > >
> > > > > Don't recall seeing this case discussed:
> > > > >
> > > > > my @iters = (undef,undef); # empty list would be
> > > > >
> > > > > run-time error!
> > > > >
> > > > > for @iters ( @iterees) {
> > > > >
> > > > > ... #   $iters[0] is alias to even iterees,
> > > > >
> > > > > $iters[1] is alias to odd ones
> > > > >
> > > > > # if @iters changes size, next time through it
> > > > >
> > > > > gets that many
> > > > >
> > > > > }
> > > >
> > > > It's not legal.  The thing after "for" must be a parenthesized list of
> > > >
> > > > scalar targets.
> > >
> > > but an easy workaround is this (my guess):
> > >
> > > for ( $iters[0], $iters[1] ) ( @iterees) {
> > >
> > > or even with the expansion??:
> > >
> > > for ( @iters[*] ) ( @iterees) {
> >
> > None of this is easy to add to the current implementation of 1-at-a-time
> >
> > foreach loops.
> >
> > I'm not convinced that it's a good idea making the step size of the iteration
> >
> > be dependant on the array's current size, as this feels like
> >
> > action-at-a-distance.
> >
> > The target(s) of a foreach loop is an alias, not an assignment - to be
> >
> > consistent with this:
> >
> > $ perl -E 'my $foo = "Hello"; for $foo ("Boo!") { say $foo; say \$foo } say $foo; say \$foo'
> >
> > Boo!
> >
> > SCALAR(0x559598381f38)
> >
> > Hello
> >
> > SCALAR(0x5595983721b0)
> >
> > it's unclear whether the the existing values of the array would be what
> >
> > was aliased, or the entire array.
> >
> > I don't think that this discussion is heading in any direction that can
> >
> > be implemented.
> >
> > Nicholas Clark

>
> > for my ($x, $y) (@a; @b; @c) { print "($x,$y) " }
> > # outputs (1,11) (111,2) (22,222) ... (5,55) (555,<undef>)
> >
> > and
> >
> > # just to make clear that it's 3 lists, not 3 arrays;
> > for my $x ((7,@a); (8,@b); (9,@c)) { print "$x " }
> > # outputs 7 8 9 1 11 111 2 22 222 ... 5 55 555
>
> Implementation wise
>


What if the syntax were extended to generally allow semicolons within round
brackets and have that mean round-robin aliasing the pieces?

my @abc = qw/ a b c /;
my @def = qw / d e f /;
my @ott = (1,2,3);

say (@abc;@def;@ott); # would output ad1be2cf3

I'm pretty sure that's currently a syntax error. The risk is that the
common typo of using a semicolon instead of a comma within an array
expansion would no longer be a syntax error, which might lead to tricky and
subtle bugs, that might make it through testing phases, as the inner arrays
would need to have more than one element each before the reordering would
happen.

the undefs returned in the slots for the short arrays (if any) would be
magical L-values that when assigned to would extend the arrays they came
from.

Good morning.

--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

Den 24.06.2021 14:56, skrev David Nicol:
>
>
> >     for my ($x, $y) (@a; @b; @c) { print "($x,$y) " }
> >     # outputs (1,11) (111,2) (22,222) ... (5,55) (555,<undef>)
> >
> > and
> >
> >     # just to make clear that it's 3 lists, not 3 arrays;
> >     for my $x ((7,@a); (8,@b); (9,@c)) { print "$x " }
> >     # outputs 7 8 9 1 11 111 2 22 222  ...  5 55 555
>
> Implementation wise
>
>
>
> What if the syntax were extended to generally allow semicolons within
> round brackets and have that mean round-robin aliasing the pieces?
>
> my @abc = qw/ a b c /;
> my @def = qw / d e f /;
> my @ott = (1,2,3);
>
> say (@abc;@def;@ott); # would output ad1be2cf3
>
Initially I thought the idea was cool, but it seems to me after taking a
step back that

for my ($x,y) (zip(@a,@b,@c) { … }

and

say zip(@abc,@def,@ott);

would be much clearer in the long run?

A simple mock implementation of a core zip method (without the
multiple-alias functioning) could be:

$ perl -wle 'use List::Util; my @a = (1,2,3); @b = (qw/a b c/); sub
zip(\@+) { return map { @{ $_ } } List::Util::zip(@_); } print zip(@a,
@b); for my $x (zip(@a,@b)) { print $x }'
1a2b3c
1
a
2
b
3
c

On Thu, Jun 24, 2021 at 07:56:53AM -0500, David Nicol wrote:
> >
> > > for my ($x, $y) (@a; @b; @c) { print "($x,$y) " }
> > > # outputs (1,11) (111,2) (22,222) ... (5,55) (555,<undef>)
> > >
> > > and
> > >
> > > # just to make clear that it's 3 lists, not 3 arrays;
> > > for my $x ((7,@a); (8,@b); (9,@c)) { print "$x " }
> > > # outputs 7 8 9 1 11 111 2 22 222 ... 5 55 555
> >
> > Implementation wise
> >
>
>
> What if the syntax were extended to generally allow semicolons within round
> brackets and have that mean round-robin aliasing the pieces?
>
> my @abc = qw/ a b c /;
> my @def = qw / d e f /;
> my @ott = (1,2,3);
>
> say (@abc;@def;@ott); # would output ad1be2cf3

Please try to stay focused. This is a thread about an RFC for `for`,
and for iterating over a single list, n-at-a-time.

Not a general syntax discussion.

(Although I approve that you're thinking about how to make syntax more
general. Good designs can be re-used, and make the language more consistent
and easier to learn. Rather too many suggested improvements are each
individual special snowflakes, with little overlap with anything else.)

`zip`ing, or whatever we'd call it, is a reasonable idea, but belongs as its
own RFC (and it's not clear to me that anyone is likely to implement it in
the near future).

Nicholas Clark

On Thu, Jun 24, 2021 at 9:30 AM Nicolas Mendoza <mendoza@pvv.ntnu.no> wrote:

> Den 24.06.2021 14:56, skrev David Nicol:
>
>
>
>> > for my ($x, $y) (@a; @b; @c) { print "($x,$y) " }
>> > # outputs (1,11) (111,2) (22,222) ... (5,55) (555,<undef>)
>> >
>> > and
>> >
>> > # just to make clear that it's 3 lists, not 3 arrays;
>> > for my $x ((7,@a); (8,@b); (9,@c)) { print "$x " }
>> > # outputs 7 8 9 1 11 111 2 22 222 ... 5 55 555
>>
>> Implementation wise
>>
>
>
> What if the syntax were extended to generally allow semicolons within
> round brackets and have that mean round-robin aliasing the pieces?
>
> my @abc = qw/ a b c /;
> my @def = qw / d e f /;
> my @ott = (1,2,3);
>
> say (@abc;@def;@ott); # would output ad1be2cf3
>
> Initially I thought the idea was cool, but it seems to me after taking a
> step back that
>
> for my ($x,y) (zip(@a,@b,@c) { … }
>
> and
>
> say zip(@abc,@def,@ott);
>
> would be much clearer in the long run?
>
> A simple mock implementation of a core zip method (without the
> multiple-alias functioning) could be:
>
> $ perl -wle 'use List::Util; my @a = (1,2,3); @b = (qw/a b c/); sub
> zip(\@+) { return map { @{ $_ } } List::Util::zip(@_); } print zip(@a, @b);
> for my $x (zip(@a,@b)) { print $x }'
> 1a2b3c
> 1
> a
> 2
> b
> 3
> c
>
>
This seems more like the mesh function from List::Util, and I see no
benefit to duplicating it to a core function.

-Dan