RE: Lists in Core?

Wouldn't XPath (and Java) list functions be considered external
functions from a PRD perspective?

Just to be clear: the *main* set processing operation function of a
(Rete) rule engine is the RuleVariable + Condition mechanism. Basically
you declare the classes (RuleVariables) you are interested in, and the
condition (parts) define the filters and joins on these. In some tools
you can specify as part of the filter that you are only interested in
members of that class in a particular list (e.g. array). This discussion
is about lists *outside* of that main Rete processing model. I think. :)

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Sandro Hawke
> Sent: 13 March 2008 22:20
> To: Gary Hallmark
> Cc: Michael Kifer; RIF WG
> Subject: Lists in Core?
> 
> 
> 
> > 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.
> 
> Gary replies:
> > 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.
> 
> What about the xpath functions on lists?
> 
>    http://www.w3.org/TR/xpath-functions/#general-seq-funcs
> 
> Those functions can all be provided by PRD engines using internal data
> structures and in BLD engines using pairs.  I don't see why they
> shouldn't be in Core, actually.  The pair view of them would only be
> available in dialects with logic functions, though.
> 
> Can't we do that?
> 
>     -- Sandro

Received on Thursday, 13 March 2008 22:48:24 UTC