4 ms·

You seem to treat NULLs as if they have a specific meaning. So then the question is this: what should count(NULL) be? Here are some options: 1) count(NULL) =

You seem to treat NULLs as if they have a specific meaning. So then the question is this: what should count(NULL) be? Here are some options: 1) count(NULL) = 0, so apparently NULL is just like an empty set at least some of the time. This means that some of the code will treat NULLs as empty sets and other code will not, leaving the burden on the programmer to keep in mind these implicit differences. 2) count(NULL) = 1 because NULL is a value, albeit a sentinel value. This can lead to tricky problems where a count() suggests that there's some data, while, in fact, there is none. 3) count(NULL) = NULL. If the idea behind this option is that sentinel value cannot be operated on, then this is pretty much like throwing an error at every NULL, which, in turn, will result in the necessity to guard many expressions with some error (NULL) handling code. One of the things to note is that an empty set has rather unambiguous semantics, while a NULL presents options each of which can be justified depending on how a particular person thinks about this special value. The line between "a value has not yet been assigned", "no value has been assigned" and "a value has been unassigned" is very blurry. On the other hand, the line between "there is no value" and "there is a value" is pretty clear.

lugg 7y ago
> You seem to treat NULLs as if they have a specific meaning. Null is a word, it has a meaning. In programming that meaning is the absence of a value. For ergonomic reasons dynamic languages will cast it to 0 or false in some situations. But that doesn't change its meaning and it doesn't mean it has multiple meanings. That would be like complaining about how most languages treat 1 == true and 0 == false. > So then the question is this: what should count(NULL) be? No, the question isn't that. The question is what is null. It is null. Count(null) does not change what null is. Null is still null. If count wants to treat null like a 0 for ergonomics it can do that. If it wants to treat it like an empty set it can do that too. If count wants to treat null as U countable and throw an error it can do that as well. If it wants to treat it as a null operation and return null it can do that too. Personally, I find 2, and 3 fucking useless so if it was my language, I would define a countable interface for null and set null = 0. Because there are no usecases where you want that to error at runtime.

lugg 7y ago

> You seem to treat NULLs as if they have a specific meaning. Null is a word, it has a meaning. In programming that meaning is the absence of a value. For ergonomic reasons dynamic languages will cast it to 0 or false in some situations. But that doesn't change its meaning and it doesn't mean it has multiple meanings. That would be like complaining about how most languages treat 1 == true and 0 == false. > So then the question is this: what should count(NULL) be? No, the question isn't that. The question is what is null. It is null. Count(null) does not change what null is. Null is still null. If count wants to treat null like a 0 for ergonomics it can do that. If it wants to treat it like an empty set it can do that too. If count wants to treat null as U countable and throw an error it can do that as well. If it wants to treat it as a null operation and return null it can do that too. Personally, I find 2, and 3 fucking useless so if it was my language, I would define a countable interface for null and set null = 0. Because there are no usecases where you want that to error at runtime.