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

[Tim Hill <drtimhill@...>]

On Oct 2, 2013, at 2:59 PM, Sean Conner <sean@conman.org> wrote:

>> 
>> 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.

Your t.seq table was "filled" with nil values from 0 to 99. Assigning a key value to nil logically deletes the key from the table (no matter what physically happens in the implementation). So the entire "for" loop did nothing to the table .. logically you still have no values in the table at the end of the loop, so it is empty, and is still a sequence (#t_seq == 0). When you assign "Boom" you break the contract, and it's no longer a sequence, hence nil.

So you get nil out twice, as you would expect. I see nothing unexpected or odd about that.

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

As noted above, t[x] = nil does not create a table entry, it deletes one if it exists, so you did not create the table in sequence order, you deleted 99 keys then added one at index 100.

>  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?

I'll say it again: Lua specifies that the # operator only returns a meaningful value if the table contains a sequence (as per the previous definition, revised or not). In other words, you can ONLY reliably use # if you know the table is a well-formed sequence. And how do you know that?

(a) Because you have control of your codebase and can confirm that you only ever generate valid sequences when you use the # operator, or
(b) Because you validate the table to make sure it IS a sequence before continuing.

Pretty much everything else is a work-around:
-- Don't use # at all
-- Use ipairs()
-- Use your own length state stored somewhere
-- etc etc.

First, it's a bit odd to have to work-around the # operator like this (witness the number of times this comes up in this forum). Second, I'm not sure why you take such issue with my suggested language change .. what is actually wrong with it?

Present behavior:
With a sequence: # returns valid length
Without a sequence: # returns arbitrary integer value that is easy to mistake for a length

Suggested behavior:
With a sequence: # returns valid length
Without a sequence: # returns nil

Why is the suggested behavior bad?

--Tim