Re: ISSUE-92: n-ary builtins

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
enough.
  - Thomas Fuller

Received on Monday, 2 March 2009 16:18:03 UTC