Re: [DTB] a counterproposal to negative guards

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

Decimal  a supertype of Integer and long, so you do not need all that
complexity:

q(numeric-add(X,1)) :- p(X), isDecimal(X).
q(0)   :- p(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?

How do you define the semantics of isError?

m

Received on Tuesday, 11 March 2008 06:31:56 UTC