Complex Terms

Every argument in a predicate can itself be a complex term consisting of a functor and several arguments (which in turn can be complex terms). The following example illustrates the use of complex terms to store shapes of different structure and of using these in performing computation.

%A DB of flat parts described by their geometric shape and weight.
%Different geometric shapes require a different number of
%parameters. Also actualkg is the actual weight of the
%part, but  unitkg is the specific weight where the actual
%weight can be easily derived from the area of the part

query: part-weight(No, Kilos)

part-weight(No, Kilos ) <- part(No, _ , actualkg(Kilos)).
part-weight(No, Kilos ) <- part(No, Shape, unitkg(K)),
                           area(Shape, A), Kilos= K * A.

area(circle(Dmtr), A1) <- A= Dmtr * Dmtr * 3.14/4.
area(rectangle(Base, Height), A1) <- A1= Base*Height.

%   part#   shape   , weight
part(322, circle(11), actualkg(34)).
part(121, rectangle(10, 20), unitkg(2.1)).

In computing this query on the first part we find that the goal in the first rule yields No=322 and Kilos=34 (the operation by which this goal and fact are made equal is called unification). The goal of the first rule fails to unify with the first fact, and instead unifies with the second one, yielding No=121, Shape=rectangle(10, 20), and K=2.1. Unsing these values, the area rules compute A and then then Kilos.

Lists

Lists are terms with two arguments, called the head and the tail of the list. Because lists are so common, a special notation is supported for lists, as follows:
• [ ] denotes an empty list,
• [X | Y] is a list with head X and tail Y
• [a, b, c, ...] is a short hand for [a | [b | [c ...]]]
Say for instance that we have facts as follows:

part(socks, [red, black, blue]).

From these facts we might want to list all the items, colors pairs (i.e., deriving a flat relation from a nested one) as follows:

query: part-color(Item, Color)

part-color(I, C) <- allcolors(I, [C|_]).
subL(I, Rest) <- subL(I, [C|Rest]).
subL(I, CL) <- part(I, CL).

Sets and Set Terms

While in lists the order of the items is important and the same item can be repeated several times, order and repetions are immaterial in sets. Thus, in the folowing list of parents and their children there is no way to tell which children was born first, nor to have two different children sharing the same name:

father(joe, {peter, mary}).
father(james, {lucy, arnold, jim}).
father(joe, {ann}).
father(jack, {}).
mother(magret, {peter, mary}).
mother(linda, {john, junior}).

query father(X, S) returns all father facts.

query father(joe, S) returns
{father(joe, {peter, mary}), father(joe, {ann})}

query mother(X, {mary, peter}) returns mother(magret, {peter, mary}),
since {mary, peter}={peter, mary} because the ordering is not important. In general set equality and unification of set terms accounts for the commutativity and idempotence properties:

• Commutativity:---sets having the same elements but a different order are equal.
  Example: {a, b} = {b, a}.
  by contrast, [a, b] [b, a].
• Idempotence:---sets having repetitious elements are equal to the same sets without the repetitions.
  Example: {a, a} = {a}.
  by contrast, [a, a] [a]
The set properties are ``built-in''; when lists are used to represent sets, the maintenance of these properties is the programmer's responsibility.

Sets Terms: Joining and Equality

Predicates can be joined on set arguments.

Example: ``create all pairs of parents having the same children''

same_children(X, Y, S) <- father(X, S), mother(Y, S).

This rule is equivalent to

same_children(X, Y, S) <- father(X, S), 
                             mother(Y, S1), S = S1.

The equality predicate can thus be applied to sets. The system supports various builtin functions on sets, including set union, difference, intersection, membership, membership, subset_of and the predicate aggregate that computes set aggregates.

Builtin Aggregates

Again say that we the followin facts:

father(joe, {peter, mary}).
father(jim, {lucy, arnold, jim}).

Then to list the number of children for each father we can use a LDL++ builtin called aggr as follows:

query: no_of_children(X, No)
no_of_children(X, No) <-  father(X, C_Set), 
                          aggr(count, C_Set, No).

This will return:

no_of_children(joe, 2)
no_of_children(jim, 3)

Thus, an aggr goal applies the aggregate in of first argument (count in the example) to the set shown in the second argument (C_Set in the example), yielding the value of the aggregate as its thirds argument (No in the example).

LDL++ supports SQL's five basic aggregates:

sum, count, max, min, avg.

When applied to an empty set { }, sum and count, return 0, while the other aggregates fail.

As discuss later, LDL++ supports user-defined aggregates.

Grouped-by Head Sets

LDL++ uses pointed brackets < > to structure the atoms derived in the head of the rules as nested relations. For instance, with suppp(Sup, Part, Price) a supplier-part-price relation, we can group by the parts, where the price is greater than 5 by suppliers as follows:

sup_parts(Sup, <Part>) <- 
               suppp(Sup, Part, Price), Price >5.

Thus, the pointed brakets denote set of values being grouped by the remaining arguments in the head. The sets so constructed can then be used to compute aggregates. Thus, to count the parts costing more than $5 sold by each supplier has, we can write:

count_parts(Sup, Cp) <- sup_parts(Sup, Part_set), 
                        aggr(count, Part_set, Cp).

LDL++, however support the computation of aggregates while the head sets are being computed. Thus, the number of parts costing more than $5 supplied by each supplied, can be expressed as follows:

sup_setof_parts(Sup, count<Part> )  <-  
                        suppp(Sup, Part, Price), Price >5.

Therefore, set aggregates can be used directly in the head of the rules or applied to a set using the aggr predicate.

   Duplicates in LDL++

---

The LDL++ system uses the following policy for duplicate elimination:
• Duplication in base relations is controlled by the keys of the relations
• Duplicates are eliminated from the tuples returned as query answers
• Duplicates are eliminated during the computation of recursive predicates
• Duplicates are NOT eliminated during the computation of nonrecursive rules
• For a head sets of the form p(X, <Y>) <- ... each value of X is returned only once (with its associated set of Y-values).

  For a head aggregate such as p(X, count<Y>) <- ... the first argument X is a unique key for the values produced by this rule. Similar rules apply to all other builtins.

Duplicates in Builtin Aggregates

Following SQL conventions, LDL++ tow different versions of builtin aggregates:
• count_dist, sum_dist, avg_dist disgregard duplicates for the builtins aggregates
• count_all, sum_all, avg_all takes into account duplicates
Take for instance:

q(X, count_dist<Y>) <- p(X, Y, Z).
e(X, count_all<Y>) <-  p(X, Y, Z).
p(a,b,1).
p(a,b,2).
p(b,c,1).

Then query: q(X,C) returns q(a, 1), q(b, 1).

But query: e(X,C) returns e(a, 2), e(b, 1).

Moreover,

• these differences are only significant for head predicates; aggregates called using aggr operate on sets which contain no duplicates, thus both versions return the same results.
• There is only one version, for the extrema aggregates min, and max
• The names sum, avg, and count are also allowed for these aggregates: in the current LDL++ implementation they, respectively, behave as sum_all, avg_all, and count_all.

The SEQ aggregates

Startin with version 5, LDL++ supports the two builtins seq and seq_dist. The first adds an unique sequence number to the tuples returned in the head, while the second does so after eliminating duplicates.

g(X,Y,seq<>)<-p(X,Y).
f(X,Y,seq_dist<>)<-p(X,Y).

p(a, b).
p(a, c).
p(a, b).

Here query: g(X,C,S) returns:

g(a,b, 1)
g(a,c, 2)
g(a,b, 3).

But query: f(X,C,S) returns:

f(a, b, 1)
f(a, c, 2).

Observe that:
• seq<> and seq_dist<> are only used with an empty list of arguments
• seq_dist provides an efficient means to eliminate aggregates in the tuples produced by a rule

The following table summarizes the built aggregates: