From: Michael Kifer <kifer@cs.sunysb.edu>

Date: Tue, 11 Mar 2008 13:17:34 -0400

To: axel@ia.urjc.es

Cc: axel@polleres.net, "Public-Rif-Wg" <public-rif-wg@w3.org>

Message-ID: <14230.1205255854@cs.sunysb.edu>

Date: Tue, 11 Mar 2008 13:17:34 -0400

To: axel@ia.urjc.es

Cc: axel@polleres.net, "Public-Rif-Wg" <public-rif-wg@w3.org>

Message-ID: <14230.1205255854@cs.sunysb.edu>

> 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 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 2 June 2009 18:33:47 GMT
*