[ruby-core:46937] [ruby-trunk - Feature #6808] Implicit index for enumerations

Issue #6808 has been updated by trans (Thomas Sawyer).


> Are the times of these benchmarks dominated by object creation or iteration? What happens if you run a small number of trials across a large array? (n = 26, a = (0...1000000).to_a)

You are correct that the difference would be less for large arrays and few iterations.

  # EACH                                 user     system      total        real
  each                               3.610000   0.050000   3.660000 (  3.671551)
  enumerator each                    3.610000   0.030000   3.640000 (  3.642515)
  each_with_index                    4.920000   0.020000   4.940000 (  4.972732)
  each and manual index              4.930000   0.010000   4.940000 (  4.950868)
  enumerator each.with_index         4.950000   0.000000   4.950000 (  4.982888)
  enumerator each and manual index   4.900000   0.000000   4.900000 (  4.911986)

  # MAP                                 user     system      total        real
  map                               4.230000   0.080000   4.310000 (  4.324616)
  enumerator map                    6.060000   0.090000   6.150000 (  6.176046)
  map and manual index              5.540000   0.070000   5.610000 (  5.633096)
  enumerator map.with_index         5.510000   0.060000   5.570000 (  5.568634)
  enumerator map and manual index   7.090000   0.200000   7.290000 (  7.287555)

But the difference looks less pronounced in this case, and on average I think programs tend to create and iterate over more small arrays, then they do large ones.

> No matter which method is faster, what happens to this code:
>
> index = 10
> offsets.each do |e|
>   index = e if condition e
>   break if index > 30
> end
>
> Does index equal 10 on the first execution of the block? Does it equal 0?

That's a fair question. I think to preserve backward compatibility, this code would have to behave just as you present it. In other words, the implicit index has been overridden by assigning it as a local variable. Which is why originally a global seemed the right choice. But can a global behave block local?

In any case, I think I will withdraw this request. Having to worry about local override or managing global that behaves block local will probably dry up any performance gain. And in retrospect I think the whole `it` idea, while good on it's face, doesn't really solve the issues it is intended to well.
I'm glad to have had the chance to discuss this and flush it out though, as it has been sitting in the back of my mind for a while.

----------------------------------------
Feature #6808: Implicit index for enumerations
https://bugs.ruby-lang.org/issues/6808#change-28600

Author: trans (Thomas Sawyer)
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0


=begin
One of the less lovely things about Ruby's otherwise elegant enumerables is the lack of ubiquitous access to the current index. Because of this, we end up with a bevy of extra methods that are little more than counter parts and compensation for other enumerable methods to gain access to the index. Examples include, #each_with_index, #each_index and (in many extension libraries) #collect_with_index. It is all rather wasteful, inelegant, and limiting. Heaven forbid we need a #select_with_index, or some other uncommon case.

No doubt this has had some discussion long in the past, but I would like revisit and offer a bnew more concrete proposal...

Thanks to Enumerator, we can now at least do:

  [:a,:b,:c].each_with_index.map{ |e, i| [i, e] }

That's great, but it has obvious shortcomings. It's long winded and it has the overhead of an Enumerator object. Ideally we would want to do this instead:

  [:a,:b,:c].map{ |e| [$i, e] }

Where $i is the implicit index. Now a global variable is surely the simplest solution. But, I can understand that some might object to the use of a global variable, despite the fact that this approach is common with regexp matches like $1, $2, etc. In that case, we could designate a new keyword. Lets call it `index`. 

  [:a,:b,:c].map{ |e| [index, e] }

We might suffer a conflict here however if someone has already used "index" as a block argument. In that case we would need Ruby to allow it to be overridden, in the same sense that one can define a public method called `class`, even though `class` is a keyword in other contexts. 

If this were all that we gained then I say it is a victory, but I'd like to consider also that we go a step further, and instead of having just "index", we have an iterative object. After all Ruby is an OOPL. In this case, the keyword would be `it` and we could do:

  [:a,:b,:c].map{ |e| [it.index, e] }

The nice thing about `it` is that it can have a few other useful methods to improve readability of code, such as `it.first?` and `it.last?` (if size is known for the enumerable). I think this is awesome solution that grants the most readability and flexibility to the language. 

Of course, having an iteration object might bring up concerns about performance, since it will add overhead to create a new iteration instance with every pass. This can be addressed by having the object be mutable, so all that needs to change is the index in the same object. A minor downside here, an `it` can't be stored by reference between passes (e.g. `prev_it = it`), but knowing this, #dup could be used if that was really necessary. If that isn't good enough to curb performance concerns, I would suggest a means of indicating the `it` object be made available. We don't want to drag Enumerator into this so `map.it{...}` is not the solution, but perhaps Ruby could recognize `;it` at the end of block arguments?

  [:a,:b,:c].map{ |e; it| [it.index, e] }

Maybe that syntax can't work, but surely something along these lines could. Personally, I doubt the overhead of mutable `it` is too much, but just in case.

To summarize, I propose an implicit mutable iteration object called `it` that allows access to the enumerations index, plus convenience methods for querying the index. Or, if that is considered too much, then at least an implicit index, either as a global variable or a special keyword. Any of these choices would be a marked improvement, allowing us to avoid the endless proliferation of `_with_index` methods.
=end



-- 
http://bugs.ruby-lang.org/