Re: Undefined variables returning nil

[William Sumner <prestonsumner@...>]

On Mar 19, 2013, at 5:57 PM, petah <lua@laufenberg.ch> wrote:

>>> On Mar 19, 2013, at 11:32 PM, William Sumner <prestonsumner@me.com> wrote:
>>> 
>>>> I know Lua only has tables. Because they're used for arrays, classes, and more, catching only undefined globals is insufficient.
>>> 
>>> Non sequitur. What else is there?
>> 
>> I'm not sure what you're calling a non sequitur, but in case you misunderstood me, silently getting nil back when accessing a non-existent table element is unsafe, particularly because tables are used for so much, so simply catching undefined global accesses and not undefined elements is insufficient.
> 
> Insufficient to /you/ but absurd to other Lua users, hence a non-sequitur. Most of us don't want tab[rnd()] to return anything but nil.
> 

> It seems you're coming from a higher-level language to claim what is sufficient and what isn't -- maybe ActionScript which IIRC differentiates between uninitialized, nil and value -- but all of this is subjective and ultimately a trade-off.

What is the trade-off of this behavior? I don't understand what it absurd or undesirable about it, why is why I'm asking. Mostly, I'm wondering if there is a technical reason that warrants avoiding it. I'm not sure it matters, but since you brought it up, I'm a C-and-friends programmer implementing a scripting API in a commercial application.

> Lua aims for simplicity and speed: nil means "is not there" unless you want to tack on a higher-level meaning, as suggested earlier.

So there is in fact a performance reason for this behavior? If not, it seems to me an undue burden on the user to avoid this gotcha when the language could catch it, as there isn't a reason I can think of why one would intentionally want an incorrect variable name bug to go uncaught.

> That's already a step up (abstraction-wise) from C/C++; if you don't appreciate Lua's simplicity and want more hand-holding then stick to a higher-level language. Or better yet, embed Lua where you think it benefits you and use other languages where you think it doesn't.

Obviously, suggesting this isn't at odds with appreciating Lua's simplicity. If improved error-catching is hand-holding, I welcome it.

>>> Hmm, thanks, but no thanks. Feel free to change your own copy of Lua in any way, shape, or form, you see fit.
>> 
>> Well, I don't understand your defensiveness; I'm just making a suggestion.
> 
> Don't read ulterior motives in this remark: you REALLY are welcome to change the language as you see fit.

Yes, of course. I'm suggesting it as an improvement to the official implementation.

Preston