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

Hello all,

 

Per my action-619: http://www.w3.org/2005/rules/wg/track/actions/619
booked during the RIF-PRD meeting of 07/10, below is an example of
"assert" and some explanations about "modify".

Regards,

 

Changhai


Syntax of "assert" in ILOG JRules


 

In production rule systems, "assert" allows to add an object to the rule
engine's working memory.

 

In ILOG JRules, the original "assert" has been renamed to "insert" to
avoid confusion with JDK's assert capability (since JDK 1.4).

 

This is an example:

 

rule BuyNewBooks

{

   when

   {

      // some conditions not expressed here, 

      // because not relevant for our discussion

   }

   then

   {

      insert Book("978-0-201-72789-0")

      {

         title = "The Power of Events";

         price = 40;

         year = 2007;

         author = "David Luckham";

         category = "computer science";

      }

   }

}

 

Explanations

*        "insert" is the rule language keyword, it is to assert a new
object.

*        "Book" is the name of the class. It is optionally followed by a
list of arguments within (). Here we want to use a constructor with one
argument: the ISBN number. The argument can be typed string, or more
strongly typed. The choice is up to the object model designer.

*        After the book object is created using the selected
constructor, the block of statements within {} is executed in the scope
of the current object. Here, we assign some values to its fields.
"title" means the field "title" of the current object.

*        After all the statements are executed, the object is reputed
well-initialized.

*        Finally, the object is added to the rule engine's working
memory. The real assertion is done here.

 

Comments

*        JRules provides the capability to select a constructor. If PRD
chooses to always use a constructor with no argument (this puts a little
constraint on the business object model), the previous statement can be
rewritten as:

 

insert Book

{

   ISBN = "978-0-201-72789-0"

   title = "The Power of Events";

   price = 40;

   year = 2007;

   author = "David Luckham";

   category = "computer science";

};

 

*        Here, the 0-arg constructor is used, and the ISBN field is
explicitly assigned.

*        Although the absence of arguments in the constructor is a
weakness, it can be acceptable in a first version.

*        JRules "insert" adds a whole object to the WM, after it is
initialized. 

*        In JRules, we don't have a notion of "asserting a field value",
we assert a whole object. But the fields can be multi-valued, and it is
possible to add a value to a multi-valued field. Can this be understood
as the capability of "asserting a field value"?

 

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.


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;

}

 

Here, the variable ?b must be previously bound to an object. Its
notation and the manner it has been bound are out of the scope of this
discussion.

 

The statement block within {} assigns new values to some fields of the
object. After all the assignments are done, the modified object is used
by the rule engine (to infer new rule instances to fire).

 

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;

 

This is much more verbose and ugly than a native "modify" statement.

 

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.

*        This indicates that an object is being modified. The engine can
be prepared accordingly. This also improves human readability.

*        It is an essential feature to build Truth Maintenance System.
Retract/assert would break the truth maintenance.

*        The paper attached in this e-mail discusses the interests of an
in-place modify, although this can be considered as an implementation
detail (a relatively significant challenge in production systems). Note
this paper has been followed by several other papers.

*        A "modify" does not necessarily mean that all the rule systems
must implement this in a specific way. It is firstly a convenient syntax
to express object modifications. In the operational semantics, we can
figure out a way, such that this can be implemented as a retract/assert
pair, or as an in-place update.