Transitive Closure A binary relation is transitive if, whenever it contains the tuples

Transcription

1 logic 63 Some useful facts about transpose: s.~r is equal to r.s, and is the image of the set s navigating backward through the relation r; r.~r is the relation that associates two atoms in the domain of the relation r when they map to a common element; when r is a function, r.~r is the equivalence relation that equates atoms with the same image. r.~r in iden therefore says that r is injective, and ~r.r in iden says that r is functional. Example. If mother is the relation that maps a child to its mother, the expression mother.~mother is the sibling relation that maps a child to its siblings (and also to itself). Discussion Why did you write ~r in r to say that r is symmetric? You might have expected ~r = r instead. The two conditions are equivalent, but I prefer the first because (1) it matches the informal statement more closely; (2) it follows the pattern of the conditions for reflexivity and transitivity; and (3) it s a good habit from an analysis perspective to write constraints in their weakest form. Admittedly, this is a bit pedantic, and it s not unreasonable to expect a definition of symmetry to be symmetric Transitive Closure A binary relation is transitive if, whenever it contains the tuples a -> b and b -> c, it also contains a -> c, or more succinctly as a relational constraint: r.r in r The transitive closure ^r of a binary relation r, or just the closure for short, is the smallest relation that contains r and is transitive. You can compute the closure by taking the relation, adding the join of the relation with itself, then adding the join of the relation with that, and so on: ^r = r + r.r + r.r.r + Example. A relation address representing an address book with multiple levels (which maps aliases and groups to groups, aliases, and addresses), and its transitive closure:

2 64 logic G0 A0 D0 G1 A1 D1 A2 D2 ^address - address address fig. 3.9 A snapshot illustrating transitive closure of a relation: the feint arcs represent the relation address; the solid arcs are those that are added to it to form its closure ^address. address = {(G0, A0), (G0, G1), (A0, D0), (G1, D0), (G1, A1), (A1, D1), (A2, D2)} ^address = {(G0, A0), (G0, G1), (A0, D0), (G1, D0), (G1, A1), (A1, D1), (A2, D2), (G0, D0), (G0, A1), (G1, D1), (G0, D1)} I ve broken the transitive closure into lines to indicate the contribution from the relation itself (on the first line), from its square address.address (on the second), and from its cube address.address. address (on the third). Fig. 3.9 shows the closure graphically. Viewing a relation as a graph, the transitive closure represents reachability. Since the relation itself represents the paths that are one step long, its square the paths that are two steps long, and so on, the closure relates one atom to another when they are connected by a path of any length (except for zero). A binary relation r is reflexive if it contains the tuple a -> a for every atom a, or as a relational constraint,

3 logic 65 iden in r The reflexive-transitive closure *r is the smallest relation that contains r and is both transitive and reflexive, and is obtained by adding the identity relation to the transitive closure: *r = ^r + iden From the graphical viewpoint, the reflexive-transitive closure relates one atom to another when they are connected by a path of any length, including zero. Because iden relates every atom in the universe to itself (as explained in section and the discussion that follows it), the reflexive-transitive closure will do so as well. Discussion Why does the reflexive-transitive closure associate irrelevant atoms? Suppose a model has a set Book of books, a set Name of names, a set Addr of addresses, a book b, and a relation addr mapping books to their contents, with the following values: Book = {(B0), (B1)} Name = {(N0), (N1)} Addr = {(D0), (D1)} b = {(B0)} addr = {(B0, N0, N1), (B0, N1, D0), (B1, N1, D1)} Then the universe will contain all the atoms univ = {(B0), (B1), (N0), (N1), (D0), (D1)} and the identity relation will map each to itself: iden = {(B0, B0), (B1, B1), (N0, N0), (N1, N1), (D0, D0), (D1, D1)} The expression ^(b.addr), denoting the direct and indirect mapping of names in book b to the names and addresses reachable, will map names to names and addresses: ^(b.addr) = {(N0, N1), (N1, D0), (N0, D0)} The expression *(b.addr) will include the tuples of both these relations. In addition to tuples such as (N0, N0), which are expected, it will also includes tuples such as (B0, B0).

4 66 logic Although this seems odd, it follows naturally from the definition of reflexive-transitive closure and the identity relation. The alternative would be to have sets implicitly associated with each relation that represent the possible members of its domain and range, which would complicate the logic. In practice this is not a problem. Closures often appear in navigation expressions, and the irrelevant self-tuples disappear in the join. For example, the names and addresses reachable in zero or more steps from a set of names friends would be denoted friends.*(b.addr), and would not include any books, because friends and Book would be disjoint. If you need to remove the extra tuples explicitly, you can always write s <: *r to restrict the closure to map only atoms in the set s. How many iterations can it take to form the closure of a relation? For a finite universe, transitive closure needs only a finite unwinding, limited by the length of the longest path in the graph. For some relations, the transitive closure requires very few unwindings even if the universe is large. Stanley Milgram s famous experiment in which he had residents of Kansas attempt to get letters to residents of Boston via acquaintances showed that it took on average only six steps for a letter to arrive [54]. If six steps were really enough to connect any two people, it would mean that the closure of the knows relation is the universal relation, and that it can be obtained in six unwindings Domain and Range Restrictions The restriction operators are used to filter relations to a given domain or range. The expression s <: r, formed from a set s and a relation r, contains those tuples of r that start with an element in s. Similarly, r :> s contains the tuples of r that end with an element in s. Restrictions can be applied to relations of any arity of two or more, but are most often applied to binary relations. Examples. Given a relation representing a multilevel address book and sets representing the aliases, groups, and addresses address = {(G0, A0), (G0, G1), (A0, D0), (G1, D0), (G1, A1), (A1, D1), (A2, D2)} Alias = {(A0), (A1), (A2)} Group = {(G0), (G1)} Addr = {(D0), (D1), (D2)}

5 logic 67 address :> Addr = {(A0, D0), (G1, D0), (A1, D1), (A2, D2)} contains the entries that map names to addresses (and not to other names); address :> Alias = {(G0, A0), (G1, A1)} contains the entries that map names to aliases; Group <: address = {(G0, A0), (G0, G1), (G1, D0), (G1, A1)} contains the entries that map groups. Applying a restriction to a binary relation is like taking the image of a set, but without dropping the matching elements. Put more formally, if r is a binary relation, and s is a set, then range (s <: r) = s.r domain (r :> s) = r.s The identity relation maps every atom in the universe to itself. Often, what we want instead is a relation that maps every atom in some set s to itself, which can be written s <: iden Override The override p ++ q of relation p by relation q is like the union, except that the tuples of q can replace the tuples of p rather than just augmenting them. Any tuple in p that matches a tuple in q by starting with the same element is dropped. The relations p and q can have any matching arity of two or more. Example. An address book might be represented by two relations, homeaddress and workaddress, mapping an alias to addresses at home and at work: homeaddress = {(A0, D1), (A1, D2), (A2, D3)} workaddress = {(A0, D0), (A1, D2)} The preferred address for an alias, which is the work address if it exists, and otherwise the home address, is given by homeaddress ++ workaddress = {(A0, D0), (A1, D2), (A2, D3)} Override can be defined in terms of simpler operators. Taking the override of p by q is equivalent to taking the union of q and what s left of p after removing the tuples that start with an element in the domain of q: p ++ q = p - (domain (q) <: p) + q Override is useful for modeling insertions into map datatypes, and assignment-like statements in programs.

6 68 logic Example. Insertion of a key k with value v into a hashmap can be modeled by representing the value of the map before and after as two relations m and m from keys to values, satisfying m = m ++ k -> v Example. The environment e of an executing Java program can be viewed (simplistically) as a relation mapping variables to object references. The effect of a Java assignment x = y with a variable on both sides can be modeled in Alloy as e = e ++ x -> y.e where e and e are the values of the environment before and after execution. The state of the heap at any point can be represented by one relation for each field (that is, instance variable) of each class. A setter statement such as x.f = y in which x and y are variables and f is a field can thus be described by f = f ++ x.e -> y.e where f and f represent the values of the field f before and after execution. Discussion What are the operator precedences? Operators have a standard precedence ranking so that constraints aren t marred by masses of parentheses. The ranking follows the usual conventions: unary operators (closure, transpose) precede binary operators; product operators (such as dot and arrow) precede sum operators (plus, minus, intersect). The details are given in appendix B. All operators associate to the left. 3.5 Constraints We ve seen how to make a constraint from two expressions using the comparison operators in and =. Larger constraints are made from smaller constraints by combining them with the standard logical operators, and by quantifying constraints that contain free variables over bindings.

7 logic Logical Operators There are two forms of each logical operator: a shorthand and a verbose form (similar to the operators used in boolean expressions in programming languages): not! negation and && conjunction or disjunction implies => implication iff <=> bi-implication The negation symbol can be combined with comparison operators, so a!= b is equivalent to not a = b, for example. The shorthand and the verbose forms are completely interchangeable, so you can write a not = b as well. There is an else keyword that can be used with the implication operator; F implies G else H is equivalent to (F and G) or ((not F) and H) Implications are often nested. The common idiom C1 implies F1 else C2 implies F2 else C3 implies F3 says that under condition C1, F1 holds, and if not, then under condition C2, F2 holds, and if not, under condition C3, F3 holds. Conjunctions of constraints are so common that we ll often omit the and operator, and wrap the entire collection of constraints in braces. So {F G H} is equivalent to F and G and H. Sometimes, it s more natural to use a conditional expression than a conditional formula. This takes the form or C implies E1 else E2 C => E1 else E2 where C is a constraint, and E1 and E2 are expressions, and has the value of E1 when C is true, and the value of E2 otherwise.

8 70 logic Examples. Suppose an address book is modeled with three relations: homeaddress and workaddress mapping an alias to addresses at home and at work, and address mapping an alias to the preferred address. To say that the preferred address for an alias a is the work address if it exists, otherwise the home address, we can write some a.workaddress => a.address = a.workaddress else a.address = a.homeaddress or, using a conditional expression a.address = some a.workaddress => a.workaddress else a.homeaddress Quantification A quantified constraint takes the form Q x: e F where F is a constraint that contains the variable x, e is an expression bounding x, and Q is a quantifier. The forms of quantification in Alloy are all x: e F F holds for every x in e; some x: e F F holds for some x in e; no x: e F F holds for no x in e; lone x: e F F holds for at most one x in e; one x: e F F holds for exactly one x in e. To remember what lone means, it might help to think of it as being short for less than or equal to one. Several variables can be bound in the same quantifier; one x: e, y: e F for example, says that there is exactly one combination of values for x and y that makes F true. Variables with the same bounding expression can share a declaration, so this constraint can also be written one x, y: e F By using the keyword disj before the declaration, you can restrict the bindings only to include ones in which the bound variables are disjoint from one another, so

9 logic 71 all disj x, y: e F means that F is true for any distinct combination of values for x and y. (See subsection for cases in which x and y are not scalars.) Examples. Given a set Address of addresses, Name of names, and a relation address representing a multilevel address book mapping names to names and addresses, some n: Name, a: Address a in n.address says that some name maps to some address (that is, the address book is not empty); no n: Name n in n.^address says that no name can be reached by lookups from itself (that is, there are no cycles in the address book); all n: Name lone d: Address d in n.address says that every name maps to at most one address; all n: Name no disj d, d : Address d + d in n.address says the same thing, but slightly differently: that for every name, there is no pair of distinct addresses that are among the results obtained by looking up the name. Quantifiers can be applied to expressions too: some e e has some tuples; no e e has no tuples; lone e e has at most one tuple; one e e has exactly one tuple. Note that some e and no e could be written e!= none and e = none respectively, but using the quantifiers makes the constraints more readable. Examples. Using the sets and relation from the previous example, some Name says that the set of names is not empty; some address says that the address book is not empty: there is some pair mapping a name to an address; no (address.addr - Name) says that nothing is mapped to addresses except for names; all n: Name lone n.address

10 72 logic says that every name maps to at most one address (more succinctly than in the previous example); all n: Name one n.address or no n.address says the same thing Higher-Order Quantification Quantified variables don t have to be scalars; they can be sets, or even multirelations. A logic that allows this is no longer first order and becomes higher order. Alloy includes such quantifications, but they cannot always be analyzed (see subsection 5.2.2). Examples. Higher-order quantifications are often useful for stating properties about operators: all s, t: set univ s + t = t + s the union operator on sets is commutative; all p, q: univ lone -> lone univ p.q in univ lone -> lone univ the join of two functions is a function too. Discussion Does Alloy allow freestanding declarations? The declaration forms described in this section can be used for quantified variables, and for fields, and they can be used as constraints (using in rather than the colon). Top-level relation declarations are not supported, as they are unnecessary (as explained in the discussion following section 4.2.2). When can higher-order quantifications be analyzed? Generally, the Alloy Analyzer cannot handle formulas that involve higher-order quantifications, so their use is discouraged. But in some useful cases, higher-order quantifiers can be eliminated by a scheme known as Skolemization, which turns a quantified variable into a free variable whose value can then be found by constraint solving. See subsection for more details. What s the difference between quantifiers and multiplicities? Novices are sometimes confused by the difference between these quantifications: lone p: some X F some p: lone X F

11 logic 73 What makes these confusing is the use of the same keywords for the quantifier and the bounding expression s multiplicity. In the first case, the quantifier is lone (at most one), and the multiplicity is some (one or more), so p is constrained to be drawn from the nonempty subsets of X, and the constraint says that F holds for at most one such subset p. In the second case, the quantifier is some, and the multiplicity is lone, so the constraint says that F holds for some option p, and is equivalent to (some p: X F) or (let p = none F) and is thus not really a higher-order quantification at all. I ve never come across a need for the first, but the second is occasionally useful. Does anyone really confuse quantifiers and multiplicities? Lest you think the last question was of purely academic interest, consider the following common (but surprisingly subtle) modeling mistake. Suppose you want to model the flushing of a line from a cache defined as a set of lines. You might be tempted to write something like one x: Line cache = cache - x reading it as pick one line so that the cache after is the cache before with that line removed. But this is not what the Alloy constraint actually means. Rather, it says there is exactly one line for which the old and new cache are related by that constraint. Note that, in particular, if the cache is empty before and after, the constraint will be false, because there will be multiple values of x in fact, any value for which the body holds. What you meant to write instead was some x: Line cache = cache - x namely that there is some line that can be removed from the cache before to obtain the cache after. This constraint allows for the cache to be empty before and after. If this were not desired, analysis would find the error, and you could then elaborate the formula, for example to some x: Line x in cache and cache = cache - x Let Expressions and Constraints When an expression appears repeatedly, or is a subexpression of a larger, complicated expression, you can factor it out. The form let x = e A

12 74 logic is short for A with each occurrence of the variable x replaced by the expression e. The body of the let, A, and thus the form as a whole, can be a constraint or an expression. Example. Revisiting the version of the address book with three relations homeaddress and workaddress mapping an alias to addresses at home and at work, and address mapping an alias to the preferred address we can say that the preferred address for an alias a is the work address if it exists, otherwise the home address, by writing or all a: Alias let w = a.workaddress a.address = some w implies w else a.homeaddress all a: Alias a.address = let w = a.workaddress some w implies w else a.homeaddress Discussion Can let bindings be recursive? No. They only provide a convenient shorthand, and don t allow recursive definitions. A variable introduced by a let on the left-hand side of a binding cannot appear on the right-hand side of the same binding, or one that precedes it in the same let construct Comprehensions Comprehensions make relations from properties. The comprehension expression {x 1 : e 1, x 2 : e 2,, x n : e n F} makes a relation with all tuples of the form x 1 -> x 2 -> -> x n for which the constraint F holds, and where the value of x i is drawn from the value of the bounding set expression e i. Each expression e i must denote a set, and not a relation of higher arity. Examples. In a multilevel address book represented by a relation address mapping names in the set Name to names and also to addresses in the set Addr,

13 logic 75 {n: Name no n.^address & Addr} is the set of names that don t resolve to any actual addresses; {n: Name, a: Addr n -> a in ^address} is a relation mapping names to addresses that corresponds to the multilevel lookup. 3.6 Declarations and Multiplicity Constraints A declaration introduces a relation name. We ve just seen how declarations are used in quantified constraints and comprehensions. Freestanding declarations of relation names make sense too, although we ll see in chapter 4 how, in the full Alloy language, these would instead be declared within signatures. The notion of multiplicity is closely tied to the notion of declaration. It s not essential in a logic, but I ve included it in this chapter because it s so useful, and can be explained independently of the structuring mechanisms of Alloy Declarations A constraint of the form relation-name : expression is called a declaration, and says that the relation named on the left has a value that is a subset of the value of the bounding expression on the right. The bounding expression is usually formed with unary relations and the arrow operator, but any expression can be used. In fact, as we shall see in the next two sections, the bounding expression on the right can actually be a more general form of expression that uses multiplicity symbols. Declarations in this form, with the colon as the operator, are used to declare bound variables in quantified formulas (section 3.5.2), and fields of signatures (section 4.2). But the same form can also constrain a previously declared variable, or an arbitrary expression (section 3.6.4), in which case the colon is replaced by the keyword in. Examples. The address relation, representing a single address book, maps names to addresses: address: Name -> Addr The addr relation, representing a collection of address books, maps books to names to addresses:

14 76 logic addr: Book -> Name -> Addr A relation address representing a multilevel address book maps names to names and addresses: address: Name -> (Name + Addr) The same relation can be declared in different ways, depending on how much information you want to put in the declaration. Example. A declaration saying that a relation address maps aliases and groups to addresses and to aliases and groups address: (Alias + Group) -> (Addr + Alias + Group) and a stronger declaration of the same relation, saying, in addition, that aliases, unlike groups, are always mapped directly to addresses: address: (Alias -> Addr) + (Group -> (Addr + Alias + Group)) Relations, not just sets, can appear on the right-hand side of declarations too. Example. An address book might be represented with three relations, representing the home, work, and preferred addresses: workaddress, homeaddress: Alias -> Addr prefaddress: workaddress + homeaddress Set Multiplicities A declaration can include multiplicity constraints, which are sometimes implicit. Multiplicities are expressed with the multiplicity keywords: set any number one exactly one lone zero or one some one or more Note that one, lone, and some are the same keywords used for quantification. The meaning of a declaration depends on the arity of the bounding expression. If it denotes a set (that is, is unary), it can be prefixed by a multiplicity keyword like this x: m e

15 logic 77 which constrains the size of the set x according to m. For a set-valued bounding expression, omitting the keyword is the same as writing one. So if no keyword appears, the declaration makes the variable a scalar. Examples RecentlyUsed: set Name says that RecentlyUsed is a subset of the set Name; senderaddress: Addr says that senderaddress is a scalar in the set Addr; sendername: lone Name says that sendername is an option: either a scalar in the set Name, or empty; receiveraddresses: some Addr says that receiveraddresses is a nonempty subset of Addr. The declarations of variables in quantified constraints are declarations of exactly the same form, and follow the same rules. The only difference is that quantifiers introduce variables that are bound within the body of the quantified constraint; the other declarations we have seen introduce free variables. Example. The quantification we saw above, some n: Name, a: Address a in n.address has two declarations, binding the scalars n and a Relation Multiplicities When the bounding expression is a relation (that is, a relation with arity greater than one), it may not be preceded by a multiplicity keyword. But if the bounding expression is constructed with the arrow operator, multiplicities can appear inside it. Suppose the declaration looks like this: r: A m -> n B where m and n are multiplicity keywords (and where A and B are, for now, sets). Then the relation r is constrained to map each member of A to n members of B, and to map m members of A to each member of B. Such a declaration can indicate the domain and range of the relation (see subsection 3.2.5), and whether or not it is functional or injective (see subsection 3.2.4): r: A -> one B a function whose domain is A;

16 78 logic r: A one -> B an injective relation whose range is B; r: A -> lone B a function that is partial over the domain A; r: A one -> one B an injective function with domain A and range B, also called a bijection from A to B; r: A some -> some B a relation with domain A and range B. Examples. Some declarations and their meaning: workaddress: Alias -> lone Addr The relation workaddress is a function that maps each member of the set Alias to at most one member of the set Addr; each alias represents at most one work address. homeaddress: Alias -> one Addr Each alias represents exactly one home address. members: Group lone -> some Addr An address belongs to at most one group, and a group contains at least one address. Multiplicities are just a shorthand, and can be replaced by standard constraints; the multiplicity constraint in r: A m -> n B can be written as all a: A n a.r all b: B m r.b but multiplicities are preferable because they are terser and easier to read. Example. The last declaration of the previous example members: Group lone -> some Addr can be replaced by members: Group -> Addr along with the constraints all g: Group some g.members

17 logic 79 all a: Addr lone members.a The expressions A and B can be arbitrary expressions, and don t have to be relation names. They also don t have to represent unary relations. The rule is generalized simply by replacing member by tuple. Thus r: A m -> n B says that r maps m tuples in A to each tuple in B, and maps each tuple in A to n tuples in B. Example. The declaration addr: (Book -> Name) -> lone Addr says that the relation addr associates at most one address with each address book and name pair Declaration Formulas Declarations usually introduce new names, but the same form can also be used to impose constraints on relations that have already been declared, or on arbitrary expressions. In this case, the subset operator in is used in place of the colon, and the term declaration formula is used. Example. For an address book represented by a relation address mapping groups and aliases to addresses address in (Group + Alias) -> Addr a declaration formula might say that each alias maps to at most one address: Alias <: address in Alias -> lone Addr A declaration formula is like any other formula, and can be combined with logical operators, placed inside the body of quantifications, and so on. Example. Given a relation addr associating address books, names and addresses, the constraint that each address book is injective (that is, maps at most one name to an address) can be written all b: Book b.addr in Name lone -> Addr Nested Multiplicities Multiplicities can be nested. Suppose you have a declaration of the form r: A -> (B m -> n C)

18 80 logic This means that, for each tuple in A, the corresponding tuples in B -> C form a relation with the given multiplicity. In the case that A is a set, the multiplicity constraint is equivalent to Similarly, all a: A a.r in B m -> n C r: (A m -> n B) -> C will be equivalent to all c: C r.c in A m -> n B Examples. The declaration addr: Book -> (Name lone -> Addr) says that, for any book, each address is associated with at most one name, and is equivalent to all b: Book b.addr in Name lone -> Addr whereas addr: (Book -> Name) lone -> Addr says that each address is associated with at most one book/name combination. The first allows an address to have different names in different books; the second does not. 3.7 Cardinality and Integers The operator # applied to a relation gives the number of tuples it contains, as an integer value. The following operators can be used to combine integers: plus minus mul div rem addition subtraction multiplication division remainder and the following to compare them: = equals < less than > greater than =< less than or equal to >= greater than or equal to

19 logic 81 Example. For a relation address address: (Group + Alias) -> Addr mapping groups and aliases to addresses, the constraint that every group has more than one address associated with it can be written all g: Group #g.address > 1 Example. Suppose an program needs to break groups of addresses into smaller subgroups. Given a relation mapping groups to the addresses they contain, address: Group -> Addr a second relation split: Group -> Group might map a group to its subgroups under the constraint that no group is a subgroup of itself no g: Group g in g.split that a group s subgroups contain all its addresses all g: split.group g.address = g.split.address and that the subgroups are disjoint all g: Group, disj g1, g2: g.split no g1.address & g2.address The cardinality constraints on the division into subgroups might be that any group with more than 5 members is split up all g: Group #g.address > 5 implies some g.split that no subgroup contains more than 5 members all g: Group.split #g.address =< 5 and that subgroups are of roughly equal size (differing from each other by at most one) all g: Group, disj g1, g2: g.split #g1.address < #g2.address implies #g2.address = #g1.address.plus[1] The expression e.sum denotes the sum of a set of integers e, and the expression sum x: e ie

20 82 logic denotes the integer obtained by summing the values of the integer expression ie for all values of the scalar x drawn from the set e. Example. The size of a group is the sum of the sizes of its subgroups: all g: split.group #g.address = (sum g : g.split #g.address) Discussion Why not use the standard symbol + for addition? An earlier version of Alloy used the same symbol for integer addition and relational union, but this complicated the language. The current version avoids any ambiguity by using distinct integer operators. What kind of form is x.plus[1]? You can think of plus, minus, etc. as predefined ternary relations representing the arithmetic operators. So this expression is just a standard join using dot and box, and could be written equivalently as plus[x,1], for example. Can integers be atoms in relations? Yes, they can. But the arithmetic operators and comparisons cannot be applied to sets, so in a formula such as S =< T, if S and T are sets of integers, the operator will actually compare their sums, as if you d written S.sum =< T.sum and similarly S.plus[T] will be short for (S.sum).plus[(T.sum)]. The equality operator, however, retains its standard meaning, so S = T will be false when S and T are distinct sets of integers, even if their sums are equal. This has the somewhat disturbing consequence that S =< T and T =< S implies S.sum = T.sum will always be true, but S =< T and T =< S implies S = T may not be. What kind of form is S.sum? That s a good question. Unfortunately, it can t be interpreted as a standard join, since the sum takes the entire set and produces a single in-

21 logic 83 teger (that is, a scalar) result. Think of sum as a special function, which, like equality, cannot be represented as a first-order relation.