Re: ACTION -393 completet

> a summary of options I added in the end of the built-ins wiki page:
> 
>  http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins
> 
> Please check the new Section
> "Syntactic Representation of built-ins in RIF"
> on that page.
> 
> 3 options are discussed and pros and cons listed, examples in
> representation syntax and XML syntax given, as far as possible:
> 
>  a. No special representation: IRIs are sufficient to identify built-ins

The proposal mentioned on the page of not allowing the use of IRIs for
the representation of logical functions seems to me an absolute choose
one.  We are creating a language for exchange *over the Web*; so, the
use of IRIs will presumably be a lot more prevalent than the use of
local symbols.  In fact, a lot of people (including me) have indicated
that they do not need local symbols at all.

Furthermore, we might want to allow people to use built-ins which are
not defined by RIF, without requiring them to specify another RIF dialect.
If we decide to allow that, then it is clearly necessary to distinguish
built-in predicates from other predicates, to indicate that people
really need to understand the built in before they can evaluate it.

In general, adopting this option would violate the following resolution
of F2F8:
"RESOLVED: no invisible extensions (official or user extensions)"

>  b. Modules

I would argue against this option for three reasons:
- it puts an additional burden on the user; he has to specify a module
whenever he wants to specify a built-in
- I expect that putting modules on the critical path for phase 1 will
introduce a significantly delay
- I see no benefit in the use of modules for built-ins; it merely seems
to impede the flexibility

>  c. Special syntax to distinguish evaluated predicates from logical
> predicates

I did not really understand the proposal.  There is a production for
ExtTerm, but it is not clear how this fits in the overall syntax. I
assume that the atomic and term productions are meant to be changed as
follows:

ATOMIC      ::= Uniterm | Equal | ExtTerm
TERM        ::= Const | Var | Uniterm | ExtTerm

This seems to me the most elegant and flexible solution, which puts the
least burden on the user.

One small comment: I do not find the "&"-prefix solution very elegant.
It suggests that "&" is a part of the name, or a modifier of the name,
where as it is meant as a modifier of the complete term. I would rather
propose:

ExtTerm ::= ' BuiltIn( ' Uniterm ' ) '

so that it is clear that the modifier applies to the complete term.

Best, Jos

> 
> comments welcome,
> Axel
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
If you live to be one hundred, you've got it
made. Very few people die past that age.
  - George Burns