Re: Regarding the name 'pairs'

[TNHarris <telliamed@...>]

On Fri, 11 Sep 2009 09:19:01 +0100
"John Hind" <john.hind@zen.co.uk> wrote:
>
> But how would you have a generalised name that would be appropriate in
> diverse cases? If there was only one iterator, this would work, call
> it something generic like "iter", but if you have two (as at present)
> you need to distinguish them by function and this raises the question,
> why not three or four? The other problem is that it is the name of the
> library function ("pairs" or "ipairs") that the "user" sees, not the
> name of the corresponding (proposed) metamethods.
> 

Yes, my proposal also includes deprecating the old library function
names in favor of new names.

There are two generic protocols for iterating any dataset: ordered
("ipairs") and unordered ("pairs"). Anything else would likely be
specific to the data and not generalisable. In that case you'd just have
to provide your own method the same as you do now. If there were only
one protocol, then it would be reasonable to invoke it implicitly, but
there are two so it's better to be explicit.

> It is important to realise that the "__pairs" and "__ipairs" proposal
> is not just the "__iter" proposal with a different name. The latter
> requires core language changes while the former is a very shallow and
> minor change which effects only the "pairs" and "ipairs" functions in
> the base library
> 

Which is why I support the first option. I prefer simpler changes that
are less likely to have unintended consequences. Unless the benefits of
a more significant change can be justified. I'm not convinced in this
case.

> I am coming round to the attractions of the "method" proposal for
> multiple iterators - the one where you can write:
> 
> for v in myobject:myiterator do print(v) end
> 

You'd get this for free if method currying were adopted. (Hopefully it
will someday.)

For the record, the forms I'm most in favor of are:

-- unordered
for values in each(set) do ... end
-- ordered
for number,values in enumerate(set) do ... end

For convenience sake, in the absence of an __enumerate metamethod, the
enumerate function could call __each but provide its own number
sequence. So you don't have provide your own counter, even when the
sequence isn't guaranteed to be stable.

It's "each" instead of "iterate" simply for being shorter. I don't
particularly care for "iter" and "enum" because they're abbreviations.
And "enum" already has a meaning in C.

-- tom
telliamed@whoopdedo.org