Re: pairs(t, skey) and ipairs(t, skey)

[Sean Conner <sean@...>]

It was thus said that the Great Tim Hill once stated:
> 
> On Oct 2, 2013, at 2:29 PM, Sean Conner <sean@conman.org> wrote:
> 
> > 
> >  Given:
> > 
> > 	t_seq = {}
> > 	for i = 1 , 99 do
> > 	  t_seq[i] = nil
> > 	end
> > 	t_seq[100] = "Boom"
> > 
> > 	t_hole = {}
> > 	t_hole[100] = "Boom"
> > 
> >  What should the following print?
> > 
> > 	print(#t_seq)
> > 	print(#t_hole)
> > 
> >  Now, given that both tables have indicies 1 through 99 as nil, and 100 as
> > "Boom", should the two be treated differently?  Why?  They are "equal" to
> > each other:
> > 
> > 	for i = 1 , 100 do
> > 	  if t_seq[i] ~= t_hole[i] then
> > 	    print("they are different")
> > 	  end
> > 	end
> > 
> >  I contend that this is just as confusing as the current behavior.
> > 
> >  How about "The # operator returns the highest integer key of the table"?
> > 
> >  -spc
> > 
> 
> They both print nil, because neither of them are sequences as per the
> definition .. I didn't put all the details in the pseudo-code to avoid
> confusion, but clearly putting "nil" in an out-of-sequence location is
> simply ignored (since by definition at that point you are merely deleted a
> nonexistent slot, which is a no-op).

  I was using your definition.  

> "We use the term sequence to denote a table where, at all times for the life
> of the table, the set of all positive numeric keys is equal to {1..n} for
> some integer n, which is called the length of the sequence."

  All the keys are positive numeric keys, starting from 1.

> This is of course a stricter definition, since it means that a sequence must
> be constructed in ascending order (it doesn't prevent you from constructing
> a table out of order, it just means such a table is not a sequence from the
> above definition). It also means a table with no numeric keys at all *is* a
> sequence, if you allow the set of positive numeric keys to be empty.

  The first table is created in sequence order, from 1 to 100.

  This, as far as I can tell, the first table is created according to your
rules.  

> We now define # as: "The # operator returns the length of a sequence, or nil
> if the table does not contain a sequence." This makes # completely
> predictable, and avoids any confusion over "tables with holes". It also
> makes # the *test* for a sequence ("if #t then … end").

  You are also concerned with checking to see if a table has a sequence, and
for some reason, don't accept that the # operator is sufficient enough to do
that because users might not know that a sequence with an embedded nil value
is not a valid sequence.  Or am I reading you wrong?

  -spc