W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2008

Re: ACTION-408: separating the different issues in the question about fct vs predicate forms for builtins

From: Axel Polleres <axel.polleres@deri.org>
Date: Sun, 03 Feb 2008 11:16:47 +0000
Message-ID: <47A5A29F.5070308@deri.org>
To: Jos de Bruijn <debruijn@inf.unibz.it>
CC: RIF WG <public-rif-wg@w3.org>

Jos de Bruijn wrote:
> 
> 
> Axel Polleres wrote:
>>
>> In the last Teleconf, I was asked to try o separate the issues coming 
>> up about fct vs predicate forms for builtins.
>>
>> Let's go: I think that there were several questions:
>>
>>
>> a) whether to allow only predicates, and no predicates, i.e.
 >> generally model functions as predicates.
> 
> I don't think anybody was proposing to not allow any built-in 
> predicates.  Certain operators, such as numeric comparison, are in fact 
> relations and are thus naturally represented as predicates.

yes, jos... was obviously a typo... sorry for the sloppy writing this 
should be:

a)
whether to allow only built-in predicates, and no built-in functions, 
i.e. generally model functions as predicates.



> Regarding the question whether to allow only built-in predicates or both 
> functions and predicates: I'm leaning towards only allowing predicates 
> (because it makes the language simpler), but I don't have a big problem 
> with functions being allowed as well.

As for not allowing functions, the example below should demonstrate that 
this would could mean considerable blow-up by necessary auxiliary 
variables when rewriting nested function terms. But I am not religious 
about any of the solutions. This said, I mean if we can cleeanly define 
them as well, built-in functions would be nicer to write sometimes, but 
we don't need them strictly speaking. Seems we pretty much agree here.

Axel

>>  For explanation, any n-ary built-in function
>>  (with a single return value)
>>   f(p1, ... , pn)
>>  in a RIF rule head or body, can be rewritten to an n+1-ary
>>  predicate as follows:
>>
>>  Head :- ..., Pred(...,f(p1, ... , pn),...),... .
>>
>>  ->
>>
>>  Head :- ..., Pred(...,Val_f,...),..., P_f(p1, ... , pn,Val_f).
>>
>>
>>  This also shoud work in the rule head:
>>
>>
>>  Pred(...,f(p1, ... , pn),...) :- ..., .
>>
>>  ->
>>
>>  Pred(...,Val_f,...) :- ...,,..., P_f(p1, ... , pn,Val_f).
>>
>>
>>  so, theoretically, built-in functions are not needed, although they
>>  provide more concise writing, especially, when they are nested,
>>  imagine:
>>
>>
>>   Head :- ..., Pred(...,p1+p2*p3-p4,...),... .
>>
>>   te rewriting looks farily ugly:
>>
>>   Head :- ..., Pred(...,Val_3,...),... Mult(p2,p3,Val_1),
>>                Add(p1,Val_1,Val_2) Minus(Val_2,p4, Val_3).
>>
>>
>>   An "intermediate" proposed solution in the last teleconf was to have
>>   one special predicate to evalutate (possibly nested) functional terms
>>   similar to the "is" predicate in Prolog.
> 
> This is yet another issue.
> And it is only relevant if we were to consider a dialect without equality.
> The only argument I heard in favor of this special predicates is that if 
> you want to use the same extterm in several places in your rule, then 
> you do not need to repeat the term, but the only variable to which you 
> assign the outcome of the function.
> 
> If we were to decide to include this predicate in the language, then we 
> need to decide whether built-in functions may only be used in this 
> special predicates or whether they may be used anywhere.
> 
>>
>> b) whether the same built-in should be (dis)allowed to have both a 
>> function and a predicate version. This is, if we allow both, built-in 
>> functions and predicates, whether there should be both a 
>> built-inpredicate And functions for the same purpose.
> 
> All kinds of built-in functions and predicates may be used with RIF that 
> have not been foreseen in the language design.  Therefore, I don't think 
> it is realistic to "allow" or "disallow" duplication.  However, if we 
> decide to use both built-in functions and predicates, then we should 
> decide for each operator we define whether it is going to be a function 
> or predicate.
> 
> Best, Jos
> 
>>
>> That was all as far as I could get it.
>> Additions/Clarifications welcome before the next Telecon!
>>
>> Axel
>>
> 


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

rdf:Resource owl:differentFrom xsd:anyURI .
Received on Sunday, 3 February 2008 11:17:18 GMT

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