[DTB] a counterproposal to negative guards

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

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


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

rdfs:Resource owl:differentFrom xsd:anyURI .

Received on Monday, 10 March 2008 22:56:37 UTC