Re: [PRD] Default conflict resolution strategy (ISSUE-64)

Christian de Sainte Marie wrote:
>
> Mark Proctor wrote:
>> I checked with Gary and clips does not implement any no-loop construct.
>
> No, but it implements a refraction (according to the user's guide for 
> version 6.0 that I use for reference):
>
> "A rule is activated if its patterns are matched by
> 1. a brand new pattern entity that did not exist before, or;
> 2. a pattern entity that did extist before but was retracted and 
> reasserted, i.e. a "clone" of the old pattern entity, and thus now a 
> new pattern entity".
>
> This is, as I understand it, exactly the reverse of what Oracle/jess 
> does (and closer to what JRules does, at least in the spirit).
no, it is very close what Oracle/Jess does.  In CLIPS (I think) and Jess 
6 (I know), fact modification is in reality a retraction of the old fact 
(aka pattern entity) and assertion of the new fact.  This leads novice 
rule authors to write many rulesets that loop forever.  Jess 7 
introduces 2 features to make it more difficult to inadvertently write 
looping rulesets.  The first is the no-loop directive on a rule.  We've 
discusssed that before.  The second is to handle modification as a 
primitive operation rather than as a pair of retract/assert primitives.  
Thus Oracle/Jess has a third rule:

"A rule is activated if its patterns are matched by
1. a brand new pattern entity that did not exist before, or;
2. a pattern entity that did exist before but was retracted and 
reasserted, i.e. a "clone" of the old pattern entity, and thus now a new 
pattern entity".
3. a slotted pattern entity that did exist before (whether or not it 
matched) that has since undergone modification of one or more slots that 
are referenced by this rule's patterns

As I understand the ILOG notion of refraction, rule 3 would instead be:
3. a pattern entity that did exist before but did not match


>
>> Btw no-loop isn't really related to default conflict resolution 
>> strategy. What is the plan there?
>
> As I see it after that discussion, PRD should not have a default 
> conflict resolution strategy at all, since everybody seems to have a 
> different default strategy.
It must be legal to specify no strategy for some ruleset in order to 
have a non-empty Core.  I guess that any ruleset that depends on the 
conflict resolution strategy must not be in Core, but I don't know how 
to enforce that.
>
> That is, we should add a way to specify the intended CR strategy 
> explicitely, and we might specify a number of "builtin" strategy that 
> every implementation must understand and be able to implement.
>
> That is: if there are such strategies that all or most engines can 
> implement. I thought that some form of no-repeat (or no-loop), some 
> form of random, some form of all at once, some form of recency and 
> some form of salience might be common enough that they might be inbuilt.
>
> And we might describe a simple algorithm for combining elementary 
> strategies, such as the one that is currently described in PRD, if 
> this is something that can be implemented easily by all or most engines.
>
> Cheers,
>
> Christian
>
>

Received on Tuesday, 5 August 2008 18:57:49 UTC