W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2008

Re: doubts about lists

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Thu, 13 Mar 2008 13:44:18 -0700
Message-ID: <47D99222.7000200@oracle.com>
To: Michael Kifer <kifer@cs.sunysb.edu>
CC: RIF WG <public-rif-wg@w3.org>

The PR systems I'm familiar with provide List builtins (e.g. at Oracle 
we use java.util.List).  Rule conditions use builtin predicates like 
contains(list, const) and builtin functions like get(list, index).  Rule 
actions use mutators like append(list, const), remove(index), as so on. 

PR cannot support the BLD list semantics.  If it could, then PR could 
also support function symbols. 

It's probably a bad idea to use the BLD list syntax for PRD given the 
semantic differences.  So I don't think it matters much to PRD what the 
BLD list syntax turns out to be.

Michael Kifer wrote:
> I started adding the lists, but doubts crept into my head after today's
> discussion. My assumption was that the reason for the lists was to
> benefit the dialects that have no function symbols.
> (As Hasan noted today, it makes little sense to add lists to dialects with
> function symbols.)
>
> But where are those dialects that do not have function symbols?  I thought
> that PR dialects need that, but PR people today said they do not.  In any
> case, it seems that there is no good reason to stuff BLD with lists, since
> BLD has function symbols. If we decide to keep lists for the future
> potential function-less dialects, then they can be added to FLD only (since
> FLD is a toolbox from which dialects pick-and-choose).
> However, I somehow doubt that there will be takers: with lists you can
> simulate arbitrary function terms and you get the same undecidability
> results for entailment.
>
>
> 	--michael  
>
>   

-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204
Received on Thursday, 13 March 2008 20:46:31 GMT

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