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

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.

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.

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

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw