Re: ISSUE-92: n-ary builtins

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 Friday, 27 February 2009 22:29:56 UTC