## Chapter 11. Rules

A rule is a logical implication that specifies how the content of a predicate can be derived from the contents of other predicates. Rules have the following syntactic form:

`Rule = Formula "<-" Formula "." .`

The arrow (`<-`) is an implication operator, read as "is implied by".

The formula on the left-hand-side of the implication operator is referred to as the head of the rule; the one on the right-hand-side is the body.

The meaning of a rule is as follows: if the formula in the body holds, then the formula in the head also holds. (We sometimes say that if the formula in the body holds, then the rule fires.)

The LogicBlox database system makes sure that the implication is satisfied: this is done by populating the predicates that occur in the head of the rule with the appropriate tuples. In other words, the predicates that occur in the head are automatically derived from the predicates that occur in the body (see also Section 11.1.2, “Incremental Maintenance”).

We sometimes informally say that a rule derives into its head predicate(s).

## Rules and the quantification of variables

### Note

The purpose of this section (which might be skipped on a first reading of this manual) is to bring to light, in an informal fashion, some of the subtleties that have to do with the quantification of variables. The information might make the wording of compiler diagnostics somewhat less mysterious. Not all the rules given in the examples are actually legal LogiQL rules: this is further elaborated at the end of the section.

A rule is a logical implication. A rule such as the following

`P <-  Q.`

corresponds to the logical statement P is implied by Q.

This statement is false only when Q holds, but P does not hold. So it is equivalent to the statement P or not Q.

For more complicated bodies we must remember to use deMorgan's rules. So, for example,

`P <-  Q, R, S.`

corresponds to the logical statement P is implied by Q and R and S. This is equivalent to P or not (Q and R and S), which, by deMorgan's rules, is equivalent to P or not Q or not R or not S.

A LogiQL rule does not contain free variables: all the variables are (implicitly) quantified.

In a rule without negations (see the section called “Negation”), all the variables are universally quantified ("for all"). However, a variable that does not occur in the head can be also be thought of as existentially quantified ("there exists").

Example 11.1. Body variables are also existentially quantified

`is_grandparent(x) <- parent(x, y), is_parent(y).`

The variable `y` occurs only in the body. The following are two natural readings of the rule:

For all `x` and all `y`, if `x` is a parent of `y` and `y` is a parent, then `x` is a grandparent.

For all `x`, if there exists a `y` such that `x` is a parent of `y` and `y` is a parent, then `x` is a grandparent.

It is easy to show that these two are indeed equivalent. Recall that head is implied by body is equivalent to head or not body, and when a universal quantifier is moved into a negation, it becomes existential: for all `x` not P holds is the same as not (exists x such that P holds).

The second reading shows that `y` can be thought of as existentially quantified (and the rule's body is then the scope of the existential quantifier). The variable `x` is not existentially quantified, because the quantifier For all `x` cannot be moved into the body: that would leave the occurrence of `x` in `is_granpdarent(x)` free (and the two occurrences would no longer refer to the same variable).

Example 11.2. Intuition can be misleading

In many cases it is more natural and less confusing to treat a variable as existentially quantified. For example, the following is an obvious statement: If, for every `y` that is a child of `x`, `y` has no child, then `x` has no grandchild.

We might be tempted to encode this as the following rule:

`has_no_grandchild(x) <- parent(x, y), has_no_child(y).`

That would be wrong. What this rule actually encodes is the slightly different statement: For all `x` and all `y`, if `y` is a child of `x` and `y` has no child, then `x` has no grandchild.

Our error becomes more obvious if we read the rule as the equivalent statement: For all `x`, if there exists a `y` such that `y` is a child of `x` and `y` has no child, then `x` has no grandchild.

We can now immediately see that if `x` has several children, and one of them has no child, it does not necessarily follow that `x` has no grandchild: `x` could have a grandchild by one of the other children.

If the body of a rule contains negated formulas, the situation gets a little more complicated. Every variable that has occurrences only inside a negated formula is quantified existentially. The scope of the existential quantifier is the smallest negated formula that contains all the occurrences (but one must be careful to distinguish between occurrences of different variables with the same name: see Example 11.4, “A quantifier limits the scope of a variable”).

Example 11.3. Variables that occur only in the scope of a negation

Given the intuitively obvious meanings of the predicates, the following defines the notion of having a grandchild:

`has_grandchild(x) <- parent(x, y), has_child(y).`

This can be used to define the notion of not having a grandchild:

`has_no_grandchild(x) <- ! has_grandchild(x).`

We can now expand the definition of `has_grandchild` to obtain:

`has_no_grandchild(x) <- ! (parent(x, y), has_child(y)).`

In this rule the variable `y` has occurrences only in the scope of the negation. The rule can be read as follows: For any `x`, `x` has no grandchild if there does not exist a `y` such that `x` is a parent of `y` and `y` has a child.

"There does not exist" (or, more precisely, "it is not true that there exists") is a negated existential quantifier. The scope of `y` is the scope of the quantifier, i.e., in this case the entire negated formula.

Since there are no other variables named `y` (see Example 11.4, “A quantifier limits the scope of a variable”) we can bring the quantifier outside the negation (thus changing it to a universal quantifier). The rule would now read: For any `x`, `x` has no grandchild if, for all `y`, it is not the case that `x` is a parent of `y` and `y` has a child.

This is equivalent to For any `x`, `x` has no grandchild if, for all `y`, either `x` is not a parent of `y` or `y` has no child.

Or, equivalently (by the definition of implication): For any `x`, `x` has no grandchild if, for every `y` such that `x` is a parent of `y`, `y` has no child. This is essentially the same as the statement with which we began Example 11.2, “Intuition can be misleading”

Example 11.4. A quantifier limits the scope of a variable

We could define `has_child` as

```has_child(x) <- daughter(x, y).
has_child(x) <- son(x, y).```

We might want to use this for defining the predicate `has_no_child`:

`has_no_child(x) <- ! daughter(x, y), ! son(x, y).`

The rule can be read as: For any `x`, if there is no `y` such that `y` is a daughter of `x` and there is no `y` such that `y` is a son of `x`, then `x` has no child.

Please note that there are two existential quantifiers, and each of them quantifies a variable named `y`. These are actually two different variables, each of them with the name `y`. The rule might as well have been written as follows:

`has_no_child(x) <- ! daughter(x, y), ! son(x, z).`

In fact, since both `y` and `z` have only one occurrence each, the recommended way to write this is

`has_no_child(x) <- ! daughter(x, _), ! son(x, _).`

The point of this example is to show that:

• the scope of a variable may be much smaller than the entire rule, and two occurrences of the same identifier need not refer to the same variable;
• increasing the scope of a quantifier may require renaming of variables.

### Note

The restrictions of LogiQL usually protect the user from most of the subtleties illustrated in this section. In particular, there is a restriction that variables must be positively bound (with the exception noted in the section called “Negation”). This restriction would make it necessary to modify the rules in our examples: all the existential quantifiers could then be regarded as having the same scope (viz., the body of the rule). For example, the rule

`has_no_child(x) <- ! daughter(x, y), ! son(x, y).`

would have to be rewritten as

```has_no_child(x) <- person(x), person(y),
! daughter(x, y), ! son(x, y).```

## Kinds of rules

There are many ways to divide LogiQL rules into categories. In particular, they can be classified as follows:

• IDB (intensional database) rules;
• EDB (extensional database) rules;
• aggregation rules.

EDB rules are often referred to as active logic, and to understand them one must understand transaction semantics in LogicBlox. We therefore defer their description to Chapter 21, Transaction Logic, in particular to Section 21.2, “Delta logic” and Section 21.3, “Events”.

Aggregation rules are the subject of Chapter 12, Aggregations.

In this chapter we focus on IDB rules.

## 11.1. Basics of IDB Rules

An IDB rule may contain an arbitrarily complex formula in the body, and a conjunction of at least one atom in the head.

The following example defines IDB rules for computing the ancestral relationship between people.

Example 11.5. Computing ancestors with IDB rules

```person(x), person_name(x:n) -> string(n).
parent(x, y) -> person(x), person(y).
ancestor(x, y) -> person(x), person(y).

ancestor(x, y) <- parent(x, y).
ancestor(x, y) <- parent(x, z), ancestor(z, y).```

The above example has two rules (in the last two lines).

The first rule reads: if `x` is a parent of `y`, then `x` is an ancestor of `y`.

The second rule reads: if `x` is a parent of `z`, and `z` is an ancestor of `y`, then `x` is an ancestor of `y`.

A database might contain the following tuples for the predicate `parent` (we use the name of a `person` to refer to its entity value):

 `"Bob"` `"Jack"` `"Bob"` `"Jill"` `"Jack"` `"Alice"`

Given the above, we can expect that evaluating the two rules in Example 11.5, “Computing ancestors with IDB rules” would result in the following tuples in `ancestor`:

 `"Bob"` `"Jack"` `"Bob"` `"Jill"` `"Jack"` `"Alice"` `"Bob"` `"Alice"`

Instead of specifying multiple rules whose head atoms refer to the same predicate, we may also specify one rule, with a disjunction in the body. The disjunction operator is the semicolon (`;`).

Example 11.6.

The following rule is equvalent to the two rules in Example 11.5, “Computing ancestors with IDB rules”:

```ancestor(x, y) <-
parent(x, y)
; parent(x, z), ancestor(z, y).```

The rule may be read: If `x` is a parent of `y`, or `x` is a parent of an ancestor of `y`, then `x` is an ancestor of `y`.

Finitely Bound Variables.  It is a requirement that a rule must compute a finite number of tuples. For example, the following is not a valid rule and will be rejected by the compiler:

```smaller_than(x, y) -> int(x), int(y).

smaller_than(x, y) <- x < y.```

It is clear that `smaller_than` would contain an infinite number of tuples (or, at least, infinite for all practical purposes). LogiQL does not allow such rules. Typically, rules that do not result in a finite number of tuples will result in compiler error messagess about invalid variable bindings. The compiler determines whether a rule results in a finite number of tuples by analyzing whether each variable that appears in the rule head is finitely bound. In this case, neither `x` nor `y` is finitely bound.

The exceptions to this requirement are value-constructing rules (Section 11.2, “Value-constructing Rules”), and derived-only rules (Section 11.3, “Derived-only Rules”).

Positively Bound Variables.  Another requirement is that every variable in the body must be:

• either positively bound (i.e., with at least one binding occurrence that is not in the scope of a negation: that binding occurrence should be "finite" in the sense described above);
• or negatively bound in the value position of a functional predicate (see the section called “Negation” for further explanations and an example).

This ensures that the search space for rule evaluation is finite.

### 11.1.1. Predicate Inference

As a programming convenience, LogiQL infers the existence of predicates from rules (and/or facts). This inference reduces the need for programmers to explicitly declare predicates (as described in Chapter 8, Predicates).

Example 11.7. Inferring predicates

The following program is equivalent to the one in Example 11.5, “Computing ancestors with IDB rules”:

```person(x), person_name(x:n) -> string(n).
parent(x, y) -> person(x), person(y).

ancestor(x, y) <- parent(x, y).
ancestor(x, y) <- parent(x, z), ancestor(z, y).```

Note that the above does not include explicit declarations of `ancestor`. From the two rules that derive into `ancestor`, the compiler infers that `ancestor` exists, and that its arity is two, with both arguments being of type `person`.

A special case of such predicate inference is inference from facts, which can be considered as rules with empty bodies. See also Section 10.1.1, “Atoms as facts”.

### 11.1.2. Incremental Maintenance

The LogicBlox database maintains the consistency of rules automatically, and in an incremental fashion.

Automatic maintenance means that the contents of the predicates named in each rule's head are consistent with the rule and the contents of the predicates mentioned in the rule's body. If the latter change over time, the head predicates will be updated accordingly, with no actions required from the programmer.

Example 11.8.

Please refer to Example 11.5, “Computing ancestors with IDB rules” and the text that follows it.

If the tuple `("Bob", "Jack")` is removed from the predicate `parent`, the tuples `("Bob", "Jack")` and `("Bob", "Alice")` will be automatically removed from predicate `ancestor`.

Similarly, if a tuple is added to `parent`, then the corresponding tuple(s) will be added to `ancestor` as well.

Incremental maintenance means that, when there is a change in the contents of predicates mentioned in the bodies of some rules, the predicates mentioned in the heads are not recomputed from scratch. The recomputation effort is proportional to the actual differences in the predicates.

## 11.2. Value-constructing Rules

Rules can be used not only to derive new tuples from existing values. They can also be used to derive, or construct, new values. Value-constructing rules use constructor predicates (Section 8.3.1, “Constructor Predicates”) to accomplish this.

The following example illustrates the use of a constructor predicate, `person_by_name`, to construct new `person` entity values.

Example 11.9.  Constructing `person` entity values by means of a rule

```person(x) -> .
person_by_name[first, last] = p -> string(first), string(last), person(p).
lang:constructor(`person_by_name).

names_input(first, last) -> string(first), string(last).

person(p), person_by_name[first, last] = p <- names_input(first, last).```

For each tuple of `(first, last)` in predicate `names_input`, the above rule creates exactly one `person` value.

Note that the rule can also be written in a simplified form:

`person_by_name[first, last] = _ <- names_input(first, last).`

A variable that occurs in the head of a rule, but not its body, would not be bound (see the section called “Bound variables and their instantiations” and Section 10.1.2, “Atoms in heads of rules”). Instead of just disallowing it, LogiQL gives it a special interpretation: it is treated as an existentially quantified variable that can be instantiated by a constructor to a freshly-created entity (see the example above). Such a variable cannot, of course, be instantiated by two different constructor atoms in the the same rule.

Example 11.10. An illegal value-constructing rule

```person_by_ssn[ssn] = p -> string(ssn), person(p).
lang:constructor(`person_by_ssn).

input_data(first, last, ssn) ->
string(first), string(last), string(ssn).

person(p),
person_by_name[fn, ln] = p,
person_by_ssn[ssn] = p <- input_data(fn, ln, ssn).```

In the above rule the variable `p` is shared by two constructor atoms: `person_by_name` and `person_by_ssn`. This code is rejected at compile-time.

## 11.3. Derived-only Rules

By default, when a rule defines what should be derived into a predicate, the result of evaluating the rule is materialized and stored as the content of that predicate. There are two reasons why this might sometimes not be desirable:

• Performance: The result of the evaluation is used infrequently, or the size of the result is disproportionately large compared to the complexity of the computation. That is, it is cheaper to simply re-evaluate the rule (and derive the contents of a predicate) than it is to store the result.
• Expressiveness: A rule specifies a computation with infinite results, and thus cannnot be materialized. However, the logic is useful in many contexts. This is often the case when a rule specifies some arithmetic computation.

In either of these situations, the programmer may choose to define derived-only rules, which must derive into derive-only predicates.

The following example illustrates the definition and use of a derived-only predicate and rule.

Example 11.11.  Defining a derived-only predicate for computing the hypotenuse of a right triangle

The predicate `hypotenuse` takes the length of the two sides of a right triangle, and computes the length of the hypotenuse. We would like to reuse the definition in many different rules. However, the result of the computation cannot possibly be materialized, as it is infinite. We therefore declare `hypotenuse` to be a derived-only predicate, by using the pragma `lang:derivationType`.

```hypotenuse[x, y] = z -> float(x), float(y), float(z).
lang:derivationType[`hypotenuse] = "Derived".

hypotenuse[x, y] = float:sqrt[x * x + y * y].```

The predicate can be used in rules where its key arguments are positively and finitely bound. For instance, we can use `hypotenuse` in the following rule to help determine which tuples in `candidates` can be the sides of a right triangle:

```candidates(x,y) -> float(x), float(y).

possible_triangles(x, y) <- candidates(x, y), hypotenuse[x, y] = _.```

A derived-only rule by itself is never evaluated. It is simply unfolded into the rule in which its derived-only predicate is used.

## 11.4. Putting it all together: general recursion

We now know the basics of LogiQL. Before moving on to more specialised constructs, let us look at a larger example (which is somewhat silly, but might nevertheless be instructive).

### Note

In what follows, we will use recursion, i.e., predicates defined by rules that use the contents of those predicates. The recursion is general : there are no special restrictions put onto the form of the recursive rules. While this works perfectly on simple examples, it might be a very serious drain on resources in the context of a larger application. See Chapter 15, Linear recursion for more information, and for ways of making recursion more efficient in those cases when what we really want is iteration.

Example 11.12. IDB rules and general recursion

To celebrate the 80 birthday of great-grandfather Abe, who is a little heavy but still very fit, the menfolk of the Johnston family decided to go for a hunting trip in Alaska. The trip will involve renting a light plane, so it is necessary to find out the total weight of all the participants.

We start by describing the men of the family, and their relationships. We represent the men not as strings, but as enities (of type `man`).

```  man(m), name(m : x) -> string(x).

father(f, son) -> man(f), man(son).

name(_ : "Abe").
name(_ : "Bob").   name(_ : "Charlie"). name(_ : "Dave").
name(_ : "Ed").    name(_ : "Fred").    name(_ : "George").
name(_ : "Henry").                      name(_ : "Ike").    name(_ : "Jim").

father(a, b),
father(a, c), father(a, d) <- name(a : "Abe"),     name(b : "Bob"),
name(c : "Charlie"),
name(d : "Dave").
father(b, e)               <- name(b : "Bob"),     name(e : "Ed").
father(c, f)               <- name(c : "Charlie"), name(f : "Fred").
father(d, g)               <- name(d : "Dave"),    name(g : "George").
father(e, h)               <- name(e : "Ed"),      name(h : "Henry").
father(g, i), father(g, j) <- name(g : "George"),  name(i : "Ike"),
name(j : "Jim").```

The weights of everyone are as follows:

```weight[m] = w -> man(m), int(w).
weight[a] = 200 <- name(a : "Abe").
weight[b] = 180 <- name(b : "Bob").
weight[c] = 170 <- name(c : "Charlie").
weight[d] = 160 <- name(d : "Dave").
weight[e] = 160 <- name(e : "Ed").
weight[f] = 150 <- name(f : "Fred").
weight[g] = 140 <- name(g : "George").
weight[h] = 100 <- name(h : "Henry").
weight[i] = 110 <- name(i : "Ike").
weight[j] = 100 <- name(j : "Jim").```

We now want to compute, for each man, the combined weight of him and all his descendants. The result for great-grandfather Abe will then be the answer we are looking for.

We declare the functional predicate that maps each `man` to his combined weight:

```// The total weight of `m` and all his descendants.
total_weight[m] = w -> man(m), int(w).```

We must now find rules that will populate this predicate with the correct information.

The first step is trivial:

```total_weight[m] = weight[m] + weight_of_descendants[m].

// The total weight of all the descendants of `m`.
weight_of_descendants[m] = w -> man(m), int(w).```

Now the fun begins: how do we define `weight_of_descendants`? You are encouraged to try it for yourself before reading on.

For men who are not fathers, this is simple enough:

`weight_of_descendants_of[m] = 0 <- man(m), ! father(m, _).`

(Notice that we had to use `man(m)` in order to bind the variable outside the negation: see the section called “Negation”.)

Since none of the men has more than three sons, we might be tempted to write:

```weight_of_descendants_of[m] = total_weight[s] +
total_weight[t] + total_weight[u]
<- father(m, s), father(m, t), father(m, u).```

A moment's reflection will show that this logic is flawed: there is nothing to prevent `s`, `t` and `u` from representing the same person, whose weight would thus be counted more than once. Moreover, if `m` has more than one son, then there are several possible ways of satisfying such a rule, and some of them will give different answers: here the LogicBlox system would help us by complaining about a functional dependency violation (FDV).

We can try to fix this:

```weight_of_descendants_of[m] = total_weight[s] +
total_weight[t] + total_weight[u]
<- father(m, s), father(m, t), father(m, u),
t != s, u != s, u != t.```

The result is that this rule never fires, and we get information only about the total weights of Fred, Ike, Henry and Jim (who have no sons). This is not surprising, since only Abe has three sons, and there is no rule that will compute the total weight for any of them.

A way out of this predicament is to provide a separate rule for each of the remaining cases: one son and two sons. For the case of two sons it would seem that the following should do the trick:

```weight_of_descendants_of[m] = total_weight[s] + total_weight[t]
<- father(m, s), father(m, t), s != t,
! (father(m, u), u != s, u != t).```

The compiler does not allow such a rule (see Example 10.25, “An illegal use of a negatively bound variable”).

An attempt to mechanically rewrite this to

```weight_of_descendants_of[m] = total_weight[s] + total_weight[t]
<- father(m, s), father(m, t), s != t,
! has_other_sons(m, s, t).

has_other_sons(m, s, t) -> man(m), man(s), man(t).
has_other_sons(m, s, t) <- father(m, u), u != s, u != t.```

will bring no immediate joy. The compiler will rightly complain that variable `t` is unbound (indeed, variable `s` is unbound, too.)

If you haven't solved the problem already, this might be a good time to experiment with various approaches. We provide just one possible solution:

```// The total weight of all the descendants of `m`.
weight_of_descendants_of[m] = w -> man(m), int(w).

weight_of_descendants_of[m] = 0 <- man(m), ! father(m, _).

weight_of_descendants_of[m] = total_weight[s]
<- father(m, s), ! has_at_least_two_sons(m).

weight_of_descendants_of[m] = total_weight[s] + total_weight[t]
<- father(m, s), father(m, t), t != s,
! has_at_least_three_sons(m).

weight_of_descendants_of[m] = total_weight[s] +
total_weight[t] + total_weight[u]
<- father(m, s), father(m, t), father(m, u),
t != s, u != s, u != t.

// Does `m` have at least two different sons?
has_at_least_two_sons(m) <- father(m, s), father(m, t), t != s.

// Does `m` have at least three different sons?
has_at_least_three_sons(m) <- father(m, s), father(m, t), father(m, u),
t != s, u != s, u != t.```