Re: Undefined variables returning nil

[petah <lua@...>]

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

Then you should know that machine-language-wise there is no "uninitialized" safeguard except MMU heap block tags and frail compiler warnings. Lua is dynamically-typed so any checks wouldn't come for free.

If your VM is faster than Lua then forget about it, or you have tricks that could benefit Lua without slowing it down they'd be most welcome.

But you're going against a 20-year old engine that's #1 in the gaming industry so the onus is on you; i.e. not "hey convince me why you didn't do it this way" but "hey I got a better way, see attached".

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

There are hash tables all over the place -- obviously adding any code in the lookup logic has a performance penalty.

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

So would the rest of us. I recently complained about error callbacks lacking granularity but those are non CPU-critical leaf cases. What you're asking for are runtime checks that I can't see working without affecting /normal/ execution.

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

Then send in the diffs & benchmarks. Seriously.

-- p