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 17:17:10 +0100
Message-ID: <49AC0686.6090209@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>
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.

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 16:18:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:54 UTC