On Jun 14, 4:43 ¨Βν¬ Ωοσσεζ ΝεξδεμσσοθΌωνεξ®®®ΐποβοψ®γονχςοτεΊ
> On Jun 14, 3:32 ¨Βν¬ Τοξω ΑςγιεςΌτ®®®ΐνεδιοθ®γονχςοτεΊ
>
>
>
> > On Sun, Jun 14, 2009 at 1:37 PM, Joel VanderWerf <vj... / path.berkeley.edu>wrote:
>
> > > What would it do with
>
> > > [ [1,2], [3,4] ].each {|x,y| ... }
>
> > One iteration, with:
>
> > x = [1,2]
> > y = [3,4]
>
> > This could be expanded out with:
>
> > [ [1,2], [3,4] ].each {|(a,b),(c,d)| ... }
>
> > and
>
> > [ [1,2], [3,4] ].each {|(x,y)| ... }
>
> > still provides the old behavior.
>
> And by "the old behavior" I presume you mean two iterations:
>
> x = 1
> y = 2
>
> x = 3
> y = 4
>
> And how is that going to happen based on inspecting arity? At least
> with 1.8.6, Proc.new {|x, y| } and Proc.new {|(x, y)| } both have an
> arity of 2.

The underlying systems has to see the difference regardless. In fact
the current implementation has to do more, b/c it has to look at the
receiver itself and see that it contains arrays as elements in order
to know how to treat it, which is rather inefficient. (Also, I think
one could argue that either this arity is wrong, or the concept of
arity needs to be expanded with an added dimension.)

> > each_slice is a lot clearer.
>
> Yes. Yes, it is.

Slice by arity seems pretty clear to me. Moreover, where is
#map_slice? It starts to look a lot clearer when we think of adding
"_slice" to every Enumerable method.

Go ahead and call out the Enumerator now.

T.