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

Re: list builtins done

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Wed, 06 May 2009 17:45:04 +0200
Message-ID: <4A01B080.4070204@inf.unibz.it>
To: Chris Welty <cawelty@gmail.com>
CC: Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
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


Received on Wednesday, 6 May 2009 15:46:06 GMT

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