5 ms·

You want empty lists because you can't iterate a null. So an empty list should be an empty list, otherwise it will require special code to check for the null ca

You want empty lists because you can't iterate a null. So an empty list should be an empty list, otherwise it will require special code to check for the null case.

shadowgovt 4y ago
Do you mean you can't iterate a null in JavaScript or in LISP? You can't iterate a null in JavaScript, but that's a design decision of the language that could have gone another way; `for (const elem of null) {do();}` could have been specified to be valid JavaScript that never calls `do()`, but it wasn't because it wasn't.
- bombolo 4y ago
  Well if you could iterate a null, you'd also be able to sum 2 nulls. And you'd need null to carry a length (of zero, I presume).
  - shadowgovt 4y ago
    Correct. Which could, of course, all be defined. - null + null === null ; list + null === list; null + list === list - null.length === 0 /* should probably make it a runtime error to write this property, or allow it but have the result be a list with length elements, all undefined */ (Note: somewhat hilariously, null + null is already defined in JavaScript. It, of course, is 0. Wat. ;) ) Whether null and empty list should be different or the same is an old argument, and both directions lead to different problems. http://thecodelesscode.com/case/6 http://thecodelesscode.com/case/6
    - bombolo 4y ago
      Why not just have empty lists instead of null then? :D Seems simpler.
      - shadowgovt 4y ago
        I agree. I use quite a few languages that don't have the "scorpion in a jar" problem where an argument might be an empty list or null (some that address it with static typing, some where the two values are the same value).
        chrisweekly 4y ago
        I'm not familiar with the "scorpion in a jar" idiom; guessing it's something like [to kill the scorpion you have to open the jar]... care to elucidate?
        shadowgovt 4y ago
        It's a reference to the "Codeless Code" link I shared upthread: 'All nothings are not equal.' A language that supports null and empty list as separate things opens the risk "what happens when the user passes null to something expecting a list?" It is, at least, something a language with good static typing can mitigate by disallowing null as a list argument. And then there's Java...
        bombolo 4y ago
        In C you sometimes have to pass int* instead of int, because you want null to signify that you aren't passing a value, rather than passing a value of 0. The two things aren't interchangeable. An empty string and a string of length 0 aren't the same thing. You'd just end up needing an extra boolean parameter for "is_null".
        shadowgovt 4y ago
        Agreed. I'm not a fan of 0===false===null for equality / truthiness tests. But "null is empty list" is categorically different and fine by me. > You'd just end up needing an extra boolean parameter Correct. Or an Option() wrapper or another box. Such an unusual construction is fine because, as you noted, the cases where one would want to distinguish null from empty list are rare. Rare cases should stick out. The fact that in JavaScript (and Java), every argument that takes an array could also take null and mean something different by it, triggering a runtime error as a result, is a design foot-gun. Rarely are both null and [] as different symbols appropriate; those languages made that a by-default-always-allowed feature.

You want empty lists because you can't iterate a null. So an empty list should be an empty list, otherwise it will require special code to check for the null case.

shadowgovt 4y ago

Do you mean you can't iterate a null in JavaScript or in LISP? You can't iterate a null in JavaScript, but that's a design decision of the language that could have gone another way; `for (const elem of null) {do();}` could have been specified to be valid JavaScript that never calls `do()`, but it wasn't because it wasn't.

bombolo 4y ago
Well if you could iterate a null, you'd also be able to sum 2 nulls. And you'd need null to carry a length (of zero, I presume).
- shadowgovt 4y ago
  Correct. Which could, of course, all be defined. - null + null === null ; list + null === list; null + list === list - null.length === 0 /* should probably make it a runtime error to write this property, or allow it but have the result be a list with length elements, all undefined */ (Note: somewhat hilariously, null + null is already defined in JavaScript. It, of course, is 0. Wat. ;) ) Whether null and empty list should be different or the same is an old argument, and both directions lead to different problems. http://thecodelesscode.com/case/6 http://thecodelesscode.com/case/6
  - bombolo 4y ago
    Why not just have empty lists instead of null then? :D Seems simpler.
    - shadowgovt 4y ago
      I agree. I use quite a few languages that don't have the "scorpion in a jar" problem where an argument might be an empty list or null (some that address it with static typing, some where the two values are the same value).
      - chrisweekly 4y ago
        I'm not familiar with the "scorpion in a jar" idiom; guessing it's something like [to kill the scorpion you have to open the jar]... care to elucidate?
        shadowgovt 4y ago
        It's a reference to the "Codeless Code" link I shared upthread: 'All nothings are not equal.' A language that supports null and empty list as separate things opens the risk "what happens when the user passes null to something expecting a list?" It is, at least, something a language with good static typing can mitigate by disallowing null as a list argument. And then there's Java...
        bombolo 4y ago
        In C you sometimes have to pass int* instead of int, because you want null to signify that you aren't passing a value, rather than passing a value of 0. The two things aren't interchangeable. An empty string and a string of length 0 aren't the same thing. You'd just end up needing an extra boolean parameter for "is_null".
        shadowgovt 4y ago
        Agreed. I'm not a fan of 0===false===null for equality / truthiness tests. But "null is empty list" is categorically different and fine by me. > You'd just end up needing an extra boolean parameter Correct. Or an Option() wrapper or another box. Such an unusual construction is fine because, as you noted, the cases where one would want to distinguish null from empty list are rare. Rare cases should stick out. The fact that in JavaScript (and Java), every argument that takes an array could also take null and mean something different by it, triggering a runtime error as a result, is a design foot-gun. Rarely are both null and [] as different symbols appropriate; those languages made that a by-default-always-allowed feature.