On Jun 14, 2009, at 9:22 PM, trans wrote:

>
>
> On Jun 14, 4:43 pm, Yossef Mendelssohn <ymen... / pobox.com> wrote:
>> On Jun 14, 3:32 pm, Tony Arcieri <t... / medioh.com> wrote:
>>
>>
>>
>>> 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.)

At this point, it sounds more like we're talking about OCaml style  
pattern matching than proc arity. I, for one, would love to see Ruby  
gain some sort of pattern matching to work with elements, but I fear  
this would be difficult to implement on top of Ruby's dynamism.

- Josh