Re: UNSAID - two test cases (dawg:unbound, issues#useMentionOp)

On Wed, Dec 22, 2004 at 02:46:41 -0800, Pat Hayes wrote:
>      There are no special cases. Any arithemtic operation involving NULL is
>      NULL, so NULL == NULL is NULL, NULL > 3 is NULL, ...
> 
>    OK, that is 'weak' 3-valued logic.  Is there any way to write an
>    expression whose value is true when its argument is NULL? If not, then
>    NULL is just a kind of universal error-mark, and does not really change
>    the underlying logic; it just makes everything more complicated  and
>    messier to state, and provides no useful functionality. In fact it is not
>    really a value in the usual sense at all; its really 'below' the real
>    values, and acts as the bottom element of a semilattice. All this will do
>    is create confusion when we try to define instance, matching etc.; and I
>    can't see that it would buy us anything positive to make up for all the
>    complication and confusion.

Yes, you can write IS NOT NULL. It invariably catches out inexperienced
programmers.
 
>      > >I have said a few times that DAWG I think should come down off the
>      fence
>      > >about tri-value logic.
>      >
>      > Do you have a test case where it makes a difference?  I have
>      difficulty
>      > seeing this as other than a difference of linguistic approach, trying
>      to
>      > use the same language for matching and for operators.
> 
>      Yes,
> 
>          SELECT ?foo
>           WHERE [ (?foo :p ?x) ] [ (?foo :q ?y) ]
>      AND ?x != ?y
> 
>      In a tri-value logic, this will only succeeed if ?x and ?y are bound, I
>      think.
> 
>    There is no way to tell until someone comes up with an exact account of
>    what != means. But why would this case differ in a 3-valued logic from the
>    way it would be handled in a 2-valued logic? It only has the effect you
>    say because the inequality requires its arguments to be bound. We can
>    specify this as a constraint on the != operator without changing the
>    underlying logic.  (BTW, there are 3-valued logics in which NULL=NULL is
>    true.)

OK, my experience of tri-value logics is limited to SQL, si I wasn't aware
of that.
 
>    I would suggest that the simplest way for us to go would be to say that if
>    any arguments are unbound, then any operator is false. So if ?x and ?y are
>    unbound then neither of ?x=?y, ?x!=?y are true.

OK, I'm farily sure I can replicate that behaviour in SQL.

>    Notice that we don't need to give these a value in the unbound case: all
>    we need to know is that they are not true in this case, so if a constraint
>    has them in it, then it fails. Our logic is always 2-valued, and the
>    values are <true> and <anything other than true>

So, :func(?x) should fail without evaluating :func()? In which case were
back to what Dan said, and dawg:bound() needs to be a special function.

- Steve

Received on Thursday, 23 December 2004 10:06:41 UTC