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

Re: ISSUE-92: n-ary builtins

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Mon, 02 Mar 2009 19:49:28 +0100
Message-ID: <49AC2A38.9040004@inf.unibz.it>
To: kifer@cs.sunysb.edu
CC: Axel Polleres <axel.polleres@deri.org>, Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Michael Kifer wrote:
> 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.

Sorry, I meant "individual symbol".


> 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>

+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
Many would be cowards if they had courage
  - Thomas Fuller
Received on Monday, 2 March 2009 18:50:31 UTC

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