4 ms·

Not a Lua developer here, what is the problem with nil? Just curious.

wruza 5y ago
Nil serves as non-existence, so cannot be used as a normal value. You can’t have a table (an object/struct in other languages) that has “existing” nil-valued key, so it breaks json schemas. You can’t have an array that contains nil, because arrays are defined to be continuous tables if consecutive indices that do not have nil. #-operator may return either 3 or 1 for {1, nil, 1} array. You delete keys and last array values by setting to nil. People tried to introduce special NIL values (an globally-available table with clear testable indication of its purpose), but it never becomes a standard and as a result every lib that requires it uses it’s own.
- pull_my_finger 5y ago
  Couldn't you just use `false`? I was pretty opposed to the talk of adding an "undefined" value in the discussion prior to 5.4. As someone who has to write javascript fairly often having a large number of falsey values is definitely not something to be desired. I think in older versions of Lua there was a pattern to include an `n` field in your tables to keep track of it's length. Lua is all about "mechanisms over policy" and provides many ways to create tables that behave like arrays in Lua.
  - cyber_kinetist 5y ago
    You're right, Javascript's undefined creates a whole new set of problems that you don't want to deal with, at least Lua didn't make that mistake. But using False for invalid key accesses seems to be a really bad idea. Sometimes you need to store boolean values in tables. When that table access returns False then you don't have a way to tell if it was from a successful key retrieval or not. (Lua solves this dillema by making that storing nil in a table is just as if nothing really happened, which is pretty reasonable) If Lua had a more fleshed-out exception system (The current one based on pcall() is a bit limited both in syntax and functionality), I think it would have been better to go for the Python route (throw exceptions for invalid table access). Don't know how it will take a toll on performance though, maybe that's the reason why it chose such a simplistic route for implementing tables?
    - nerdponx 5y ago
      I actually like having both "nil" and "undefined" in Javascript! "Absence of value" is different from "data that happens to be some kind of empty data point". Also part of the issue is function arguments, there's no arity-checking by default.
      - wruza 5y ago
        Right, and it allows for arguments of functions and destructurizers to be undefined for default and null for null. Absent and empty are really different concepts. These being merged, separate, implicit or explicit, all may be hard to manage, but at least in the case of (undefined & null) it is a most uncrippled value system. JSON also got it right, allowing null but not undefined. At the end of the day all that matters is a programmer’s convenience. Corner cases exist everywhere. With all flaws of js, this is where it shines: var t = undefined var u = {b:1} var {a=42, b=true} = {undefined, …t, …u} // a==42, b==1 Another related issue with Lua is: table.insert(t, string.gsub(s, “1”, “2”)) -- happy debugging It is full of these little design decisions that put your feet to danger not any less than others.
      - int_19h 5y ago
        It would be nice if "undefined" consistently meant absence, but it's not quite that: console.log('foo' in {foo: undefined}); // true!
cyber_kinetist 5y ago
It's not that nil itself is a problem, the real issue is that every invalid table key access doesn't trigger an exception (like Python), but instead returns nil. And everything in Lua is built with tables (including whole class systems), so this makes debugging a serious pain in the ass. In fact, even global variable accesses are designed to work as table accesses to _G (the global table), so if you make a typo then the interpreter doesn't say that you've mispelled a variable but instead silently gives you nil. This leads to all sorts of weird bugs that are very hard to track down. Probably the number one reason why I ditched the language for something else.

Nil serves as non-existence, so cannot be used as a normal value. You can’t have a table (an object/struct in other languages) that has “existing” nil-valued key, so it breaks json schemas. You can’t have an array that contains nil, because arrays are defined to be continuous tables if consecutive indices that do not have nil. #-operator may return either 3 or 1 for {1, nil, 1} array. You delete keys and last array values by setting to nil. People tried to introduce special NIL values (an globally-available table with clear testable indication of its purpose), but it never becomes a standard and as a result every lib that requires it uses it’s own.

pull_my_finger 5y ago
Couldn't you just use `false`? I was pretty opposed to the talk of adding an "undefined" value in the discussion prior to 5.4. As someone who has to write javascript fairly often having a large number of falsey values is definitely not something to be desired. I think in older versions of Lua there was a pattern to include an `n` field in your tables to keep track of it's length. Lua is all about "mechanisms over policy" and provides many ways to create tables that behave like arrays in Lua.
- cyber_kinetist 5y ago
  You're right, Javascript's undefined creates a whole new set of problems that you don't want to deal with, at least Lua didn't make that mistake. But using False for invalid key accesses seems to be a really bad idea. Sometimes you need to store boolean values in tables. When that table access returns False then you don't have a way to tell if it was from a successful key retrieval or not. (Lua solves this dillema by making that storing nil in a table is just as if nothing really happened, which is pretty reasonable) If Lua had a more fleshed-out exception system (The current one based on pcall() is a bit limited both in syntax and functionality), I think it would have been better to go for the Python route (throw exceptions for invalid table access). Don't know how it will take a toll on performance though, maybe that's the reason why it chose such a simplistic route for implementing tables?
  - nerdponx 5y ago
    I actually like having both "nil" and "undefined" in Javascript! "Absence of value" is different from "data that happens to be some kind of empty data point". Also part of the issue is function arguments, there's no arity-checking by default.
    - wruza 5y ago
      Right, and it allows for arguments of functions and destructurizers to be undefined for default and null for null. Absent and empty are really different concepts. These being merged, separate, implicit or explicit, all may be hard to manage, but at least in the case of (undefined & null) it is a most uncrippled value system. JSON also got it right, allowing null but not undefined. At the end of the day all that matters is a programmer’s convenience. Corner cases exist everywhere. With all flaws of js, this is where it shines: var t = undefined var u = {b:1} var {a=42, b=true} = {undefined, …t, …u} // a==42, b==1 Another related issue with Lua is: table.insert(t, string.gsub(s, “1”, “2”)) -- happy debugging It is full of these little design decisions that put your feet to danger not any less than others.
    - int_19h 5y ago
      It would be nice if "undefined" consistently meant absence, but it's not quite that: console.log('foo' in {foo: undefined}); // true!

cyber_kinetist 5y ago

It's not that nil itself is a problem, the real issue is that every invalid table key access doesn't trigger an exception (like Python), but instead returns nil. And everything in Lua is built with tables (including whole class systems), so this makes debugging a serious pain in the ass. In fact, even global variable accesses are designed to work as table accesses to _G (the global table), so if you make a typo then the interpreter doesn't say that you've mispelled a variable but instead silently gives you nil. This leads to all sorts of weird bugs that are very hard to track down. Probably the number one reason why I ditched the language for something else.