But I don't consider Euclidean modulo to be a "remainder" at all in an arithmetic sense, but as an operator of its own kind. Why therefore shouldn't there be a modulo operator (distinct from the remainder operator) which need not accord with the definition of the standard division and remainder? Effectively, in terms of the OP's question, why shouldn't C have furnished both operators? (2/2)

@IMSoP, the reason I'm distinguishing "remainder" from "modulo" is precisely to emphasise that they are not the same operators and they are not used for the same purposes. The fact that many languages conflate the terminology or furnish only one of these two operators is part of the problem. We accept the equation of quotient * divisor + remainder = dividend should constrain the definition of the division and remainder operator pair. (1/2)

@IMSoP, whilst it seems obvious why the definition of remainder should be related to integer division, why should the modulo necessarily be related to division (or at least, why should it have to be related to the same definition of division as the remainder operator)?

In my answer, I give the example of a vet treating an injured dog, and not knowing whether it is a dog whose owner is unknown for the time being, or an unowned (wild) dog. What unites all these different cases or meanings, is the need usually for some kind of special handling. That's what Null provides in SQL. Many people get hung up on what Null means about the world, rather than what it means for the automatic data processing which the database performs. Has that clarified anything? (2/2)

@dan04, if you read all my contributions on this question, including my answer and my various comments, you'll see that I don't accept that Null represents only "missing" or "unknown" information. It is actually a multi-purpose value that represents many meanings. As I say in my comment above, it is standard to consider that Null breaks down into "missing" and "inapplicable". But in my view, there is a third case of how Null is used, which is where the meaning is certainly either one of missing or inapplicable, but the organisation doesn't and cannot know which. (1/2)

@dan04, it would be different from those values in the same way that Null in SQL (which represents all three of known-missing, known-inapplicable, and unknown) is different from them. Your question is potentially confusing to me, because I'm not sure whether you are asking specifically about some subtlety of Codd's 4VL idea, or whether you are asking a very general question about why it is useful to have a separate Null value in SQL?

I've found out why so much Microsoft documentation refers to UNKNOWN despite no relevant use of that keyword in TSQL. It's because the ISO/IEC 9075 standard itself uses the Unknown term. But the standard also states that Unknown is synonymous with Null typed as the Boolean/Bit data type.

@qwr, yes in logical expressions that is correct, although I don't recall the SQL syntax explicitly acknowledging an UNKNOWN keyword - it appears to be a term that is only used in documentation. But as I say in my answer, the use of Null goes beyond logical contexts, far beyond any 3VL theoretical formalism. Every data type includes Null in its domain, and all kinds of operators have some kind of special handling for Null. Like how bats resemble both birds and mice, SQL draws clearly upon many preceding theories, but without fully corresponding to any of them.

@qwr, Codd himself tried to make a 4VL-style logical system which distinguished "missing" and "inapplicable". One problem is that it produces a vast and unmanageable number of possible logical operators. But in my opinion, the main reason it doesn't work is because the programmer often doesn't actually know whether the information is missing or inapplicable, so you end up with known-missing, known-inapplicable, and unknown, and sometimes whether something is missing or inapplicable depends on the use/purpose of the query.

@IMSoP, again I'm thinking on the hoof, but I'm not sure there is "only one type of Null". Certainly, there is no independent Null data type. And the Null constant/keyword can be cast to a specific type. Perhaps the design of SQL has been muddled in this area.

@Quassnoi, I'm sure I occasionally use NOT IN on non-nullable columns - so it's not completely without usefulness - but it's become second-nature to me to scrutinise filtering very carefully whenever nullable columns are involved. It's certainly an area of the language that feels like it could withstand some kind of improvement.

@MichaelTsang, yes many languages have something called null and it is used for some of the same purposes. But the overall mechanics are quite different. Also, I'm not quite sure whether SQL treats nullable fields as being union types. On the whole, I'd be inclined to say it treats the domains of all data types as intrinsically containing a null value - rather than thinking of it as being like a conventional data type plus a bolted-on null value. These kinds of subtleties are why a so-called "impedance mismatch" occurs between SQL and other conventional programming languages.

@Quassnoi, we had an interesting discussion of this a few months ago on SE.SE. The basic principle is that scalar operators propagate nulls, and aggregate operators eliminate nulls. The reason for this distinction in approach is because each caters to the most common use, and the opposite behaviour is easily achieved with a few extra words of syntax localised to the operator in question. If either kind of operator worked like the other, then the current behaviour which each kind of operator has becomes extremely difficult to achieve. So any extra consistency would be foolish.

Surprised I haven't seen Visual Basic (i.e. classic VB) mentioned as an example of a popular language having this syntax. Calls where there is no return value (or an unused and unassigned return value), can be made without brackets - like Add a, b to represent Add(a, b). I've never liked the feature myself, but I guess it was supposed to resemble assembly language instructions (hence why it isn't compatible with return values).