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

Re: binding patterns [was: Re: list builtins done]

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Thu, 7 May 2009 13:42:41 -0700
Message-ID: <499257640905071342p33cb802dq3831c3883c326dc8@mail.gmail.com>
To: Jos de Bruijn <debruijn@inf.unibz.it>
Cc: Chris Welty <cawelty@gmail.com>, Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
+1 to require all builtin equality tests to have bound args

On Thu, May 7, 2009 at 3:25 AM, Jos de Bruijn <debruijn@inf.unibz.it> wrote:
> Actually, I now have a doubt about the binding patterns with an unbound
> variable for the predicates pred:string-equal, pred:date-equal,
> pred:dateTime-equal, pred:duration-equal, pred:date-equal,
> pred:time-equal, pred:XMLLiteral-equal, pred:matches-language-range, and
> pred:text-equal. The problem is that in implementations you would need
> to generate all things that are somehow equal according to the XSD
> definition. For example, for dateTime, you need to generate all dateTime
> values that represent the same point in time (e.g., by varying the
> timezone). matches-language-range is probably even harder.
>
> There is no problem for the datatypes for which equality and identity
> are the same (e.g., string). However, for reasons of symmetry, I would
> prefer to have the same binding patterns for all datatype equality
> predicates.
>
> So, I propose to remove all binding patterns involving a "u" for the
> predicates pred:string-equal, pred:date-equal, pred:dateTime-equal,
> pred:duration-equal, pred:date-equal, pred:time-equal,
> pred:XMLLiteral-equal, pred:matches-language-range, and pred:text-equal.
>
>
> Best, Jos
>
> Gary Hallmark wrote:
>> I think most PRD translators will have to detect builtins with unbound
>> arguments and generate some "tricky" code because most PRD engines don't
>> allow any unbound arguments to their builtins. I don't object because I
>> think the few builtins that permit unbound args are quite useful.
>>
>> Jos de Bruijn wrote:
>>> Action completed. The only additional binding pattern (besides the
>>> trivial (b...b) patterns) that I thought should be defined was for
>>> pred:list-contains (b,u).
>>>
>>>
>>> Best, Jos
>>>
>>> Jos de Bruijn wrote:
>>>
>>>> I can do this. Please assign me an action.
>>>>
>>>>
>>>> Jos
>>>>
>>>> Chris Welty wrote:
>>>>
>>>>> So who will take up the issue of binding patterns for lists in Core?
>>>>> Axel? Jos?
>>>>>
>>>>> -Chris
>>>>>
>>>>> Sandro Hawke wrote:
>>>>>
>>>>>> I think the DTB section on RIF lists [1] is now ready for review for
>>>>>> Last Call.  A few notes and questions:
>>>>>>
>>>>>>    * I removed the func:delete function, because           (a) it's
>>>>>> not in xpath,
>>>>>>           (b) it's confusingly similar to func:remove, and
>>>>>>           (c) it's trivial emulated:                  func:delete(L,
>>>>>> I) = func:except(L, func:make-list(I))
>>>>>>
>>>>>>      Some other functions are trivial emulated, but they're in
>>>>>> xpath.  I
>>>>>>      think the bar is higher for us adding functions.  This way, the
>>>>>>      only ones we're adding are is-list, list-contains, make-list, and
>>>>>>      get.  list-contains is that only the can be emulated:
>>>>>>              list-contains(L, I) iff count(index-of(L, I)) > 0
>>>>>> but I think we specifically discussed that and agreed it was
>>>>>>      worthwhile to have list-contains.
>>>>>>
>>>>>>      Obviously, if someone actually wants it, I'm okay with putting
>>>>>>      func:delete back in.
>>>>>>
>>>>>>    * This section has examples.  I could trivially suppress them
>>>>>> for now
>>>>>>      (this wiki-text is generated by a program [2]), if they bother
>>>>>>      people.  I like them.  They have all been checked by my demo code
>>>>>>      [3].  I'm willing to make similar examples for the rest of DTB
>>>>>> for
>>>>>>      a later edition.
>>>>>>
>>>>>>    * I don't know the right binding pattern for list-contains.
>>>>>> Above, I
>>>>>>      was assuming it was (b,b), but I can imagine some utility to all
>>>>>>      binding patterns, and at least (b,u) seems pretty reasonable.
>>>>>> It's
>>>>>>      not clear to me whether PR systems would do what I'm imagining
>>>>>> with
>>>>>>      that, but it'd be nice to write rules like:
>>>>>>
>>>>>>          forall M (                   if
>>>>>> list-contains(eg:list_of_friends, M)
>>>>>>            then eg:is_friend(M)
>>>>>>          )
>>>>>>
>>>>>>      Without it, I guess you'd need some much more cumbersome
>>>>>>      tail-recursive rules like this:
>>>>>>
>>>>>>          friend_list(eg:list_of_friends)              forall L M (
>>>>>>            if   friend_list(L) and
>>>>>>                 get(L, 0) = M
>>>>>>            then eg:is_friend(M)
>>>>>>          )
>>>>>>          forall L  (
>>>>>>            if   friend_list(L) and
>>>>>>                 count(L) > 0
>>>>>>            then friend_list(sublist(L, 1))
>>>>>>          )
>>>>>>
>>>>>>      PR folks, what do you want, there?
>>>>>>
>>>>>> I think that it.  This complete ACTION-760.
>>>>>>        -- Sandro
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> http://www.w3.org/2005/rules/wiki/DTB#Functions_and_Predicates_on_RIF_Lists
>>>>>>
>>>>>>
>>>>>> [2] http://dev.w3.org/cvsweb/2009/rif/list_builtins.py
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>
> --
> +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
>



-- 
Cheers,

Gary Hallmark
Received on Thursday, 7 May 2009 20:43:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:08 GMT