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

Jon Heggland wrote:
> In article <1134005990.468784.63910_at_f14g2000cwb.googlegroups.com>,
> boston103_at_hotmail.com says...
[...]
> > 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).

You've got me here ;). Of course, in PLs you do not need a separate biconditional because the equality operator (or more precisely expression equivalence operator) is sufficient due to the fact that PLs do not use multivalued logic. If they did the biconditional truth table might have been different from the '==' predicate definition.

> > 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.

It's not my schema but rather Codd's. That's how the SQL handles NULL (whatever NULL is assumed to mean).

>
> > > 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.

What truth values, as well as various markers (I use the word marker in Codd's sense, not in Date's) represent is in the designer(s)/modeller(s) mind. The logical connective meaning, or if you prefer the fancy word 'semantics', is given by its truth table solely. Whether the connective behaviour, for example equivalence/biconditional, suits our purpose is another matter altogether.

> > 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.

Codd tried with his four-valued logic, but apparently not many folks liked the idea of splitting the original NULL labelling a bunch of things into smaller nulls meaning presumably separate thingies.

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

It's not entirely the same sure, due to the prominent role logic plays in reasoning, but if one looks at the integers, rationals, 3VLs as just algebraic structures with different rules of the game, the analogy should be obvious.

> --
> Jon
Received on Thu Dec 08 2005 - 14:50:22 CET