W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2009

Re: ISSUE-92: n-ary builtins

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Mon, 16 Mar 2009 09:58:39 +0000
Message-ID: <49BE22CF.1050203@hplb.hpl.hp.com>
To: Chris Welty <cawelty@gmail.com>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
I can live with any of these options.

I've a mild preference for 3b (and in general 3*) over 1*.
[Jena already has variable arity external predicates and it would be 
slightly easier to do the translation if that was available in RIF.]


Chris Welty wrote:
> Lets try to find an option we can all live with from among the following 
> on the upcoming telecon:
> Current status:
> Of the options discussed so far, the following remain:
> 1. Make it clear this is only shorthand for the purposes of writing DTB, 
> and that all  rulesets must use a fixed arity function/predicate
> 1a. specify one rather than n different functions. So, in the case of 
> concat we would only have a binary string concatenation function. 
> Clearly all the others can be built from this base case.
> 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).
> Description:
> 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?
Received on Monday, 16 March 2009 09:59:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:54 UTC