RE: [PRD] ACTION-619: Examples in JRules to support discussion on Assert and Modify

Hi Gary,

Thanks for your quick feedback.

I understand that on the first part, about "assert", we are essentially
aligned.

On the second part ("modify"), at least we share a common understanding
about the "modify" capability provided by the various PR engines. I
think "modify" can be considered a convenient syntax, let's try to not
enforce too much on the operational semantics. Let's discuss this
further in the next meetings.

Changhai

-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: jeudi 9 octobre 2008 23:58
To: Changhai Ke
Cc: RIF WG
Subject: Re: [PRD] ACTION-619: Examples in JRules to support discussion
on Assert and Modify



>

> insert Book
>
> {
>
> ISBN = "978-0-201-72789-0"
>
> title = "The Power of Events";
>
> price = 40;
>
> year = 2007;
>
> author = "David Luckham";
>
> category = "computer science";
>
> };
>
Oracle has a textual rule language (called simply "RL") similar to 
yours. We say
assert(new Book(ISBN: "978-0-201-72789-0", title: "The Power of Events",

price: 40));
We can also call a constructor with arguments.
>
>
> *Non-intrusiveness of production rule systems*
>
> One important principle of rule systems is being non-intrusive to the 
> application object model. When an application is designed, the 
> designer had the freedom to design the object model accordingly to the

> pure business requirements. He/she designs the classes, and will 
> assign them some constructors. Some of them will be with arguments, 
> and some others without arguments, this is dictated by the business 
> needs. Only later on, the rules are brought into the application. The 
> rules must then infer on an existing object model, without requiring 
> altering it. As a matter of fact, people who write rules are not 
> necessarily the ones who designed the object model. In this sense, the

> inability of RIF-PRD to use any form of constructor violates the 
> non-intrusiveness of production rule systems. Although we are making 
> the decision to support only zero-arg constructors, this weakness 
> needs to be understood and acknowledged.
>
Yes, we need constructors and methods (eventually).
>
>
>     */Necessity of a "modify" for RIF-PRD/*
>
> A "modify" statement signifies that an object in the WM is being 
> modified, one or several fields are assigned new values. Below is an 
> example of syntax in ILOG JRules:
>
> modify ?b
>
> {
> year = 2008;
>
> price = 50;
>
> }
>
RL is similar: modify(b, year: 2008, price: 50)
>
> Without a "modify" statement, the object modifications will be 
> simulated in RIF-PRD using "retract" and "assert", in the following
way:
>
> retract ?b;
>
> ?b.year = 2008;
>
> ?b.price = 50;
>
> insert ?b;
>
No. They will be implemented as either:

a. Core compatible mode
?b[year->2008 price->50]

b. PRD mode
retract(?b[year->?oldyear price->?oldprice])
?b[year->2008 price->50]

In Core there is no retract, so you just add new slots/values. Whether 
this "works" depends on the use case.
I might be in favor of allowing wildcards in place of ?oldyear and 
?oldprice, so our translators don't have to add these variables and bind

them in the condition.
>
> This is much more verbose and ugly than a native "modify" statement.
>
Be careful. Beauty is subjective, and we aren't designing an end-user 
language. This is an interchange format that we would like to work 
across many kinds of rule engines, not just production rules. That said,

I could see that
modify(?b[year->2008 price->50])
could be short for
retract(?b[year->* price->*])
?b[year->2008 price->50]

However, it has the same semantics.
>
> A modify statement is required for a few reasons:
>
> * Most of the production rule systems, ILOG JRules, Fair Isaac, 
> Drools, Jess, OPS family, have a "modify" statement (sometimes called 
> "change", "update") etc.
>
yes but they probably have subtle differences in both syntax and 
semantics. We must define a standard syntax and semantics, and we must 
consider non-PR systems as well.
>
> * This indicates that an object is being modified. The engine can be 
> prepared accordingly. This also improves human readability.
>
The only real issue is: can you build a translator? Neither your engine 
nor your users will see RIF-PRD syntax.
>
> * It is an essential feature to build Truth Maintenance System. 
> Retract/assert would break the truth maintenance.
>
I don't think this is true if you consider the frame-level 
retract/assert. You seem to have been assuming object-level retract -- 
which is not correct.

Received on Friday, 10 October 2008 09:53:28 UTC