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.
- 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
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).
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?
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...
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".
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.
> 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.
Wat?
You might want to signify that you are not passing a list instead of you are passing an empty list. Same way that happens with any other type…
> The fact that in JavaScript (and Java)
Well in JS it's completely insane. With typed python if you say "list of XXX" null is not accepted by linters. You need to specify it's also an option.
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.