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

[Andrew Starks <andrew.starks@...>]

On Wednesday, October 2, 2013, Tim Hill  wrote:
> On Oct 1, 2013, at 6:51 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
>
> >> I still feel the lack of an efficient way to determine if a table t is a sequence is a significant hole in the language/runtime.
> >
> > Why would you need that? If you care that a table is a sequence, then either
> > you have created the table and know it or you have been handed a table and
> > can assume whoever gave you the table honors the contract with you to use
> > only sequences. What am I missing?
> >
>
> Seriously??? I'm stunned that you can seriously suggest "honors the contract with you to use only sequences". So if a 3rd party makes an error calling an API, it's ok to crash or generate random erroneous results? Where in Lua is this behavior exhibited? Is it ok for load() to skip over syntax errors and create an executable chunk that runs random, invalid, VM code? Is it ok for math.sin() to generate random values if I supply a boolean or (non numeric) string as input?
>
>
> No, these APIs validate and rigorously check input over their expected domain, and generate errors accordingly (what else *is* syntax checking???). They protect themselves from erroneous input, as much as is practical. This is fundamental good design of APIs.
>
>
> Scenario: I'm writing a 3rd party API that expects a sequence as an argument. For example:
>
> sum = addSeq(t)
> The addSeq() function adds all the values in the sequence in the table t, returning the total.
>
> What should the API do if "t" is NOT a sequence:
> (a) Return a random result that is incorrect (or crash)
> (b) Flag an error
>
> You seem to be suggesting (a), which I regard as flawed. I think a robust API should validate it's input as far as possible. Checking simple things like the types of arguments is trivial, so I can check that "t" is a table (as I should). But can I check that "t" is a sequence? No, I can't, or at least I can't trivially .. I can write a checker function, but any Lua code that checks to see if "t" is indeed a sequence is non-trivial and expensive .. and this is the hole: It's EXPENSIVE to check that a table is a sequence and therefore EXPENSIVE to create a robust API in this case.
>
>
> The root of this problem is as I have said before: The Lua contract says "If a table is a sequence, the # operator returns the length of the sequence, if a table is not a sequence, the # operator generates an undefined result. There is no language provided facility to validate if a table is a sequence".
>
>
> This translates to: "The # operator has undefined behavior if you cannot assert that a table is a sequence".
>
> This in turn translates to: "You cannot use the # operator unless you originate or trust all tables with which you use it".
>
> This finally means, "You cannot use the # operator with tables supplied by 3rd parties (such as callers of an API, since you cannot trust 3rd parties)".
>
> Which leaves you scratching your head if you wish to write a robust, production quality, API that can accept 3rd party input and generate sane results if that input is expected to be a sequence.
>
> --Tim

Tim,

I follow your logic, but could you define "sequence" in the context if Lua?

What would you propose should happen when I have a table that I wish to treat as a sequence and also as a hash, for keys that are non-numeric? What about a table with integer keys that have no holes, but also have floating point values or 0/negative keys?

I think you'd agree that Lua has been somewhat successful, so far. So, how much speed is this feature worth? If another complex type is needed, then is it worth that complexity?

If I'm interacting with a C library that promises that I'll receive a sequence, is it appropriate for me to double check that fact in a scripting language?

If I'm parsing text input, such as JOSN, it seems like I can scan for a sequence pretty efficiently, but I could be wrong...

I too have wanted a sequence. I'm surprised there isn't a library for one, actually. If tables could report that their numeric keys were in a sequence and it cost me nothing in speed and only a function call tucked into the "table" library, in terms of complexity, then I'm all for it. But if not, then Lua is fine for what Lua does, IMHO. 

Your reasoning seems compelling and your reputation speaks for itself. It's too bad that the tone was over the top and unnecessarily disrespectful.

Thanks.

-Andrew