Re: ISSUE-92: n-ary builtins

On Mon, 02 Mar 2009 17:17:10 +0100
Jos de Bruijn <debruijn@inf.unibz.it> wrote:

> I do not really object to option 3, but it is not an option I prefer.
> Given that predicate and constant symbols are distinct, it seems awkward
> that predicate/function symbols of different arities are not distinct.

Did you mean "predicates and function symbols"? Because predicate symbols are
constant symbols.

Anyway, we have several possible routes to go with an option-3-like solution:

3a. Remove all the well-formedness requirements. The same symbol can have
    several arities, can be a pred, func, and an individual in different
    contexts.
3b. To keep the separation between preds, funcs, and individuals, but pred,
    func, external symbols can have multiple arities.

3c. To keep things as before, but for external symbols to allow multiple arities
    (and maybe even allow them to be funcs and preds in different contexts).

michael

> I would object to option 2 on the grounds that it is a very ugly way to
> write the semantics of a language.
> 
> I don't see the point of option number 1: why is this notation necessary
> for the purposes of this specification?
> 
> I would prefer option 1a): specify one rather than n different
> functions. so, in the case of concat we would only have a binary string
> concatenation function.
> 
> 
> Best, Jos
> 
> 
> Michael Kifer wrote:
> > It was Jos who was objecting to (3), not me. If he still objects,
> > my earlier msg proposed a compromise.
> > 
> > michael
> > 
> > On Fri, 27 Feb 2009 22:15:34 +0000
> > Axel Polleres <axel.polleres@deri.org> wrote:
> > 
> >> slight problem for 3 if feasible (BLD editors need to agree, but 
> >> Michael's mail seems to indicate green light?)
> >>
> >> Chris Welty wrote:
> >>> The basic issue is that BLD (and core) require all predicates and 
> >>> functions to have a fixed arity, but in DTB we reuse many xpath/xquery 
> >>> functions and predicates, and there are several that do not have a fixed 
> >>> arity (e.g. concat).      In DTB, the treatment of these operators is 
> >>> unclear:
> >>>
> >>> "numbering the different versions of the respective built-ins and 
> >>> treating the unnumbered version as syntactic sugar, i.e. for instance 
> >>> instead of External( func:concat2( str1, str2) ) and External( 
> >>> func:concat3( str1 str2 str3 ) ) we allow the equivalent forms External( 
> >>> func:concat( str1, str2) ) and External( func:concat( str1 str2 str3 ) )."
> >>>
> >>> Does this mean that BLD should allow rulesets to use concat with any 
> >>> arity, or does it mean that for the purposes of DTB we write concat as a 
> >>> shortcut for whichever (concat2, concat3, etc) is appropriate?
> >>>
> >>> Possible solutions:
> >>>
> >>> 1) Make it clear this is only for the purposes of writing DTB, and that 
> >>> all rulesets must use a fixed arity function/predicate
> >>>
> >>> 2) Allow for some preprocessing step in RIF implementations where 
> >>> functions like concat are replaced with their fixed-arity equivalents
> >>>
> >>> 3) Change BLD to allow for arbitrary arity functions and predicates. I 
> >>> can find no formal resolution to make preds/funs fixed arity, however it 
> >>> would be a major change to a LC document (BLD).  At the last telecon, no 
> >>> one was opposed to this change on technical grounds, only because of the 
> >>> LC status.
> >>>
> >>> </chair>
> >>> I prefer option 1.
> >>> <chair>
> >>>
> >>>
> >>>
> >>
> > 
>

Received on Monday, 2 March 2009 17:57:56 UTC