Re: list builtins done

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

Received on Thursday, 7 May 2009 06:59:39 UTC