Builtin variable for loop index in foreach #15700
Comments
From @epaCreated by @epaPerl's foreach loop is very handy. But sometimes you write some code foreach my $thing (@things) { you now have to rewrite your code as foreach my Moreover, to get back the original semantics (where $thing is an alias I was wondering, if perl knows internally how far along in @things we Suppose that the currently unused $# variable were used for this. foreach my $thing (@things) { There are snags with this (even assuming it could be implemented with foreach (qw(a b c)) { say $_; foreach (qw(x y z)) { say $_ } say $_ } and I imagine a similar rule could apply to $#. I suggest this new feature because I hope it is something perl already Perl Info |
From @iabynOn Mon, Nov 07, 2016 at 03:46:12AM -0800, Ed Avis wrote:
Currently perl doesn't always know the index. For ranges, e.g. (1..10) and
If we did this this, we would have to either: * update $# on each loop iteration, which would slow down all loop -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @epaDave Mitchell wrote:
But for numeric ranges, if you know the current value it is just a subtraction to find its index.
I think it would still be faster than the equivalent handwritten code using an $i variable, though? My concern would be whether in all cases 'searching the context stack for a loop' -- This email is intended only for the person to whom it is addressed and may contain confidential information. Any retransmission, copying, disclosure or other use of, this information by persons other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material. This email is for information only and is not intended as an offer or solicitation for the purchase or sale of any financial instrument. Wadhwani Asset Management LLP is a Limited Liability Partnership registered in England (OC303168) with registered office at 9th Floor Orion House, 5 Upper St Martin’s Lane, London, WC2H 9EA. It is authorised and regulated by the Financial Conduct Authority. |
From @demerphqOn 8 November 2016 at 11:35, Ed Avis <eda@waniasset.com> wrote:
An alternative would be to introduce a new keyword, say "for_with_index". Then you could say for_with_index (LIST) { and perl would know it has to do the extra bookkeeping to populate $#. But personally I would not use Yves |
From @iabynOn Tue, Nov 08, 2016 at 10:35:07AM +0000, Ed Avis wrote:
No, at the point where you have iterated 'for (11..20) {}' say, 7 times, -- |
From @epaDave Mitchell wrote:
Ah I see. So when looping over a range, the start of the range would need to be stored -- This email is intended only for the person to whom it is addressed and may contain confidential information. Any retransmission, copying, disclosure or other use of, this information by persons other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material. This email is for information only and is not intended as an offer or solicitation for the purchase or sale of any financial instrument. Wadhwani Asset Management LLP is a Limited Liability Partnership registered in England (OC303168) with registered office at 9th Floor Orion House, 5 Upper St Martin’s Lane, London, WC2H 9EA. It is authorised and regulated by the Financial Conduct Authority. |
From @ap* Dave Mitchell <davem@iabyn.com> [2016-11-08 11:36]:
The latter would be fine, just as a new builtin `loopindex` instead of How much overhead (size, speed) on scopes would we incur if each frame Regards, |
From @kentfredricOn 28 November 2016 at 13:48, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
There's a third option, its not well employed, but it could be: At parse time, the Perl compiler parsing the for { } block *lexically* And then upon detecting that variable's usage in its block, then instruments This would mean *no* performance impact for existing code at runtime, Though it could be tricky. for ( ... ) { Here $# is only instrumenting its direct parent. Logically, it would be like imagining there was a builtin called for_idx my($#, $value) ( .... ) { } And I think that latter form is quite easy to reason about. You don't have to worry about distant subs secretly poking at $# and Also, my memory tells me lexicals are rather fast in comparison to -- KENTNL - https://metacpan.org/author/KENTNL |
From @iabynOn Mon, Nov 28, 2016 at 01:48:23AM +0100, Aristotle Pagaltzis wrote:
Well there are two approaches: the one you describe, or to add a new In addition to extra field needed in the loop struct to store or calculate pp_next() etc are already optimised to check if the top context is a loop -- |
From @epaTranslating the loop at compile time into a new builtin foreach_idx sounds sensible, and it effectively automates what the programmer currently has do to in the code. But if $# is a lexical scoped at compile time to the for loop, it won't be available in subroutines called from the loop. This makes it inconsistent with next/last/redo, which do work from subroutines (matching the enclosing loop at run time). Personally speaking I'd be fine with that (I consider always allowing 'next' from a subroutine something of a wart on the language) but I just mention the asymmetry. One advantage of a new builtin loopidx rather than $# would be that you could specify loopidx(LABEL). This might be another point in favour of a compile-time translation approach, that it could allow loopidx(LABEL) to be implemented more easily. |
From @iabynOn Mon, Nov 28, 2016 at 08:14:23PM +1300, Kent Fredric wrote:
what about: for (...) {
Marginally faster. For example '$x = 1' uses about 3% fewer CPU instructions -- |
From @kentfredricOn 28 November 2016 at 21:53, Dave Mitchell <davem@iabyn.com> wrote:
Yeah. That's the annoyingest part of this idea. I don't know how to If we take a different tack and propose, instead of some arcane magic,
That can take *two* variables: for_idx my $key, $value ( @array ) { Then we get the benefit of explicitness, the benefit of clarity, and Theoretically, this idea could even be prototyped on CPAN. If anyone goes in this direction, may I also tempt them with: for_assoc my $a, $b, $c ( @array ) { } Which would be a "more perlish" way of the sort of idea people are trying to for_assoc my $key, $value ( %hash ) { } #justsayin But as you can see, this is kinda bikeshed territory: Its clearly the I'm not in any hurry to shoehorn one of these proposals into Perl wrongly. :) -- KENTNL - https://metacpan.org/author/KENTNL |
From @iabynOn Mon, Nov 28, 2016 at 08:53:34AM +0000, Dave Mitchell wrote:
Another approach would be to extend the for syntax, e.g. for -> $i (....) { say "$i: $_" } for a suitable bikeshedding of '->'. -- |
From @kentfredricOn 28 November 2016 at 22:34, Dave Mitchell <davem@iabyn.com> wrote:
Yeah. There's also the possibility of a future of list expanding + for my $iter -> my $a, $b, $c ( @items ) { Where "$iter" would only increment once for every three @items pooled Though I would expect any implementation we choose to have the values -- KENTNL - https://metacpan.org/author/KENTNL |
From @hvdsOn Mon, 28 Nov 2016 01:21:43 -0800, kentfredric@gmail.com wrote:
You also get the benefit that *you already have this*: while (my($key, $value) = each @array) { I'm guessing (wildly) that when the "experimental each on scalar" deprecation advances to removal, we could consider extending each() to lists to support: while (my($key, $value) = each(1, 2, @many)) { ... } Hugo |
From zefram@fysh.orgHugo van der Sanden via RT wrote:
Except that foreach and while/each have completely different behaviour
Wouldn't be possible. There's nowhere for the iterator to live. -zefram |
From zefram@fysh.orgThe proposed for_idx should be implemented on CPAN, not in the core. -zefram |
From @xsawyerxOn Tue, 05 Dec 2017 21:39:48 -0800, zefram@fysh.org wrote:
Considering these comments, I agree it should first go on CPAN to see if it's valuable enough to add into core. The concerns revolved slowing down loops and introducing a new keyword for a feature that is not certain to be widely used. I would rather exercise caution here. |
|
@xsawyerx - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#130038 (status was 'rejected')
Searchable as RT130038$
The text was updated successfully, but these errors were encountered: