Re: So what's null then if it's not nothing?

In article <1134005990.468784.63910_at_f14g2000cwb.googlegroups.com>, boston103_at_hotmail.com says...
> Sure, I know what the words mean in a specific context, but throwing
> them around in a technical argument smells a bit of marketing talk.

Well, like I said in the previous post, now that I think I've finally understood your arguments, my objections are mainly based on principles for good language design. Now, whether's that's "technical" or not ...

> > select * from test2 where (a < 12) = (b > 15);
> >
> > This query is a syntax error in SQL, or at least in Oracle. You can
> > reformulate the condition to an equivalent, syntactically allowed
> > expression, but why should we have to?
>
> Apparently, the language designer(s) decided that the demand for the
> built-in equivalence won't be stong enough.

My point is that the grammar necessary to *disallow* such expressions is more complicated than an orthogonal one. And less powerful.

> Besides, it's trivial to
> write a custom function in major SQL dialects that implements any of
> your favourite connectives missing from the vendor-supplied set, as it
> is equally trivial in any major PL. Can you name many PLs that support
> equivalence (biconditional) ?

If you mean support of boolean expressions like "(a < 12) = (b > 15)", it's harder to find any that does *not*. Try Java (substituting '==' for '=', of course).

> > 2. If we nevertheless were to store 3VL logical values in a database, it
> > makes sense to use NULL for UNKNOWN.
>
> Not quite.
>
> It makes sense to use any words you like to represent more truth
> degrees than just two. If you need more truth degrees (interpreted
> according to your needs), naturally, you have to use more truth values
> to represent those truth degrees. Additionally (or in the first
> place), you have to extend your various data domains with desired
> markers to represent missing, unknown, or some other values besides
> non-pathological values. The names for such markers may be the same
> as, or different from, the logical truth values. Also, you'd want
> to extend various predicates (e.g. equality, greater than, etc) so
> that they would accepte the new markers as arguments and produced truth
> values that make sense in your model.

Right. And I object to this for language design reasons. Tell me if you're interested. :)

> Alternatively, you might not want anything of the kind and just do
> what Date and other relational purists suggest one should do.

I'll have to say that your scheme above seems to have all the flaws of Date's 2VL "special values" approach, *plus* extra complexity. YMMV.

> > 3. Attributes of the type "(3VL) logical value" cannot be 'missing'
> > NULL, only UNKNOWN NULL.
>
> They can mean anything that makes sense in your model. In particular,
> if it makes sense, the 3VL NULL (or if you choose the name UNKNOWN) can
> represent the notion of undefined, senseless, contradictory,
> whatever you have in mind. By themselves, they represent nothing but
> a bunch of symbols and rules to combine them into WFFs.

I'd say that what they mean---the semantics---is defined to a great extend by how their operators work. For example, you can (like Celko, I think, in the bowling discount thread) intend a NULL date to "mean" the end of time, but that doesn't fit well with how the '<' operator works with NULLs. If you can redefine those operators, fine, but then you have the problem that the user never knows how your NULLs behave. Wasn't "consistent treatment" one of Codd's commandments? Not that I necessarily endorse those, but ...

> Now, obviously, INT.NULL is not the same as L.NULL,
> they have different rules of game and represent different notions
> (existing in you mind). If you find using NULL confusing in a
> situation like that, by all means, using different names, e.g.
> MISSING for the former and UNKNOWN for the latter.

I most certainly will. I can't think of any reason at all to use the same name for completely different concepts with different behaviour. SQL queries like "select * from T where null = null" would have to be banned; you'd have to introduce some mechanism for specifying what *kind* of null you mean. And in that case, why not use a different same to begin with? It makes no sense.

(And using numerals for both integers and floats is not the same thing. Tell me if you're interested. :)

-- 
Jon