Why Rules?

From KynetxDocs

KRL is a deterministic rule language. This means that KRL programs consist of a set of rules that take an action when triggered. KRL is not imperative, object-oriented, or functional. consequently writing a KRL ruleset is not a traditional programming task.

A active ruleset is a reactive system; a ruleset in KNS is constantly in contact with it's environment and reacts when something in the environment prompts it. When a ruleset is run, it takes action on the environment. In it's current instantiation, KRL reacts to people visiting Web pages by producing actions that modify those pages.

Conditional Actions

At its simplest, a rule is a conditional action. The action can be any thing appropriate to the domain. For augmenting Web pages (KRL's primary use at present), actions are page modifiers. In the future, when KRL is used to augment domains other than the Web (like email clients), other actions will be available. When a rule's action is taken, we say that the rule "fired."

Note that the action is conditional. The action is taken only when the rule is selected and its premise is true. In the first stage, the rule is selected, or not, based on the conditions given in the select statement. This most often consists, in the Web domain, of a regular expression match with the URL of the page being augmented. Thus, the first stage the rule is selected only for certain Web pages.

The second stage of the conditional firing of the rule is testing it's premise which consists of a predicate that is used to test the context that the rule is being evaluated in. This check is done after the rule's prelude section, where values are declared, so that it has the benefit of any computation needed to create or manipulate the context.

It is possible to write a selector that always selects and the predicate is optional, so some rules always fire. But most interesting rulesets will contain actions that only take place under certain circumstances.

Rule Language Benefits

Rule languages offer important benefits over traditional languages in the task of context automation, or augmenting experience based on user context:

• Rules are especially adapted to programming reactive systems. That is, systems that react to something in the environment. In the case of KRL, that environmental action is the end user visiting a Web page.

• Each rule is clearly identifiable with a specific portion of the experience. In the case of Web augmentation, each rule is selected for, and thus applied to, a specific set of pages.

• Rules build experience accretively. As more and more rules are added, they add to the over all experience. We take pains with the design of KRL to ensure rules play nicely together. Of course, that can't be guaranteed, but the goal is to allow rules to be added in ways that build the experience for the end user.

• Rules are declarative. They specify what action is taken when certain conditions are true. KRL tempers that with a very capable expression language and lots of built-in intrinsics for more efficient programming.

Rule Language Pitfalls and Tips

Here are a few things to do and a few to avoid:

• Remember that you're building a ruleset that reacts to people visiting Web pages. A KRL application is the result of multiple, possibly interdependent, conditional actions taking place over a number of reactions.

• Fail early. Determine what page, or set of pages, your rule applies to and write the regular expression in the selector to carefully select only those pages. This will make your ruleset more efficient.

• A ruleset in KRL always evaluates each rule once, in order (although an individual rule may have a loop). So, it's possible for a rule earlier in a ruleset to set something up for rules that come later.

• Rules cannot have else arms on the conditional, so if the predicate is false, the rule "fails" and does not "fire." If you want to take an action based on the opposite condition, in a rule language you are forced to write another rule.

• Even though the rule itself cannot have en else action, conditional expressions (with else) are available in the expression language and conditional postludes (with else) are available for setting persistants or explicit logging.

• The KRL expression language does not support mutatable variables. But persistants can be used to store mutatable values that are remembered from invocation to invocation.

• Persistants can be used to have one rule impact the behavior of another.