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

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.

  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.

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.

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 Friday, 1 February 2008 22:03:15 UTC