Re: [DTB] a counterproposal to negative guards

>   q(0)   :- p(X), isError(X+1).

OK, I did not notice X+1 in there. But I think it is artificial. Also, what
if + is overloaded and X can be a string? If you do not like number->string
conversions, what if you wanted X+1 to be an error for floats, but not integers?


	--michael  

> > 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).
> 
> ok, but that was not the point... so what?
> Eqally Jos isNotNumeric-solution is valid, but still we need the negated
> Guards.
> 
> >> 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?
> 
> I thought that this is what the subgroup which you were in at the F2F
> could tell me :-) Seriously, I was making preassuming that we have a
> special error value, which needs to be in every domain of a RIF
> interpretaion for error. That was one of the proposals, wasn't it?
> Admittedly, I cannot read a solution out of theminutes of the F2F.... :-(
> If I miss it, can you send me the pointer?
> 
> Axel
> 
> Axel
> 
>

Received on Tuesday, 11 March 2008 17:20:30 UTC