Re: [DTB] a counterproposal to negative guards

Thinking a bit about implementation, implementing built-ins such as 
isNotString might not be as straightforward as I had originally thought.

Namely, isString and isNotString will give rise to multiple minimal models:
for every IRI a there will be one minimal model in which isString(a) is 
true and one minimal model in which isNotString(a) is true.  The lack of 
a single minimal model prevents the use of the usual fixpoint operator 
for computation.

Best, Jos

Jos de Bruijn wrote:
> 
>> I was talking to Harold about the DTB document again and we agreed 
>> both that we do not really like the "negative guards", because they 
>> seem to introduce some special form of negation, which is a bit weird, 
>> as otherwise negation is not part of bld...
>>
>> Now let's take the use case, which I suppose brought up the whole idea 
>> about negative guards:
>>
>>
>>  I assume the idea was that guards where meant to do some type 
>> checking to prevent other builtins to fail with an error... so we need 
>> these for instance to right something like:
>>
>>  q(X+1) :- p(X)    if X is numeric.
>>  q(0)   :- p(X)    if X is not Numeric.
> 
> the most natural way to write these rules is:
> 
> q(X+1) :- p(X), isNumeric(X).
> q(0)   :- p(X), isNotNumeric(X).
> 
> In fact, I would be surprised if we would not have the isNumeric and 
> isNotNumeric built-in predicates. (we already have built-ins such as 
> numeric-add and numeric-subtract, so it will be rather silly not to have 
> the isNumeric and isNotNumeric predicates)
> 
> Now, your first example is an approximation of this, which can be 
> simplified, as Michael pointed out.
> 
> Your second example is an encoding that one can only understand if one 
> would know about the intricacies of the way RIF deals with errors.
> Guards are a way to prevent errors occurring in the first place, thereby 
> not requiring users to know about the intricacies of the semantics of 
> errors.
> 
> 
> Then, I would argue that having "negation" in built-in predicates does 
> not introduce negation in the language.
> In fact, we already have negation in our built-in predicates.  For 
> example, greater-than is the negation of less-or-equal.
> Perhaps negation is also not the proper term in this context.  Perhaps 
> we should rather talk about "complement".  Greater-than is the 
> complement of less-or-equal; numeric-equal is the complement of 
> numeric-unequal; isNumeric is the complement of isNotNumeric.
> Implementing the complement of a built-in predicate is as complex as 
> implementing the built-in predicate itself.
> 
> Finally, complement of built-in predicates is quite different from the 
> (default) negation usual in logic programs.
> Consider isNotString(ex:myiri).  This statement may be true in some 
> models, and false in others.
> Consider now not isString(ex:myiri). This statement is true in the 
> minimal model, because it is not known that ex:myiri is a string.
> 
> 
> Best, Jos
> 
> 
>>
>> i.e. to make a case distinction, concerning whether the arbuments are 
>> "allowed" for the built-in which should e "guarded".
>>
>> Now with the current means we would need to  write this something like 
>> as follows:
>>
>>  q(numeric-add(X,1)) :- p(X), isInteger(X) .
>>  q(numeric-add(X,1)) :- p(X), isDecimal(X) .
>>  q(numeric-add(X,1)) :- p(X), isLong(X) .
>>
>>  q(0)   :- p(X), isNotInteger(X), isNotLong(X), isNotDecimal(X).
>>
>> whereas we could write this simpler and without negative guards if we 
>> just add one more guard except the current datatypeguards:
>>
>>  q(numeric-add(X,1)) :- p(X), isInteger(X) .
>>  q(numeric-add(X,1)) :- p(X), isDecimal(X) .
>>  q(numeric-add(X,1)) :- p(X), isLong(X) .
>>  q(0)   :- p(X), isError(X+1).
>>
>> I don't know whether this solves all use cases for negative guards, but,
>> before buying into sneaking in some form of negation which we can later
>> on have in dialects with negation for free... maybe adding the 
>> isError() guard for the moment and leaving out the negative guards 
>> would do for the moment?
>>
>> Axel
>>
>>
> 

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw