|
1 | 1 | # Glossary
|
2 |
| -This is a glossary of terminology (possibly) used in the chalk crate. |
3 | 2 |
|
4 |
| -## Binary connective |
5 |
| -There are sixteen logical connectives on two boolean variables. The most |
6 |
| -interesting in this context are listed below. There is also a truth table given |
7 |
| -which encodes the possible results of the operations like this |
8 |
| - |
9 |
| -``` |
10 |
| -f(false, false) f(false, true) f(true, false) f(true, true). |
11 |
| -``` |
12 |
| - |
13 |
| -As a shorthand the resulting truth table is encoded with `true = 1` and `false = |
14 |
| -0`. |
15 |
| - |
16 |
| -| Truth table | Operator symbol | Common name | |
17 |
| -|-------------|-----------------|----------------------------------| |
18 |
| -| 0001 | && | Conjunction; and | |
19 |
| -| 1001 | <=> | Equivalence; if and only if; iff | |
20 |
| -| 1101 | => | Implication; if ... then | |
21 |
| - |
22 |
| -## Binder |
23 |
| -A binder is an expression that binds a literal to a certain expression. |
24 |
| -Examples for binders: |
25 |
| - |
26 |
| -- The universal quantifier `forall(a)` states that a certain condition holds for |
27 |
| - all allowed values for `a`. |
28 |
| -- A function definition `f(x) = a * x` is a binder for the variable `x` whereas |
29 |
| - `a` is a free variable. |
30 |
| -- A sum `\sum_n x_n` binds the index variable `n`. |
31 |
| - |
32 |
| -## Canonical Form |
33 |
| -A formula in canonical form has the property that its DeBruijn indices are |
34 |
| -minimized. For example when the formula `forall<0, 1> { 0: A && 1: B }` is |
35 |
| -processed, both "branches" `0: A` and `1: B` are processed individually. The |
36 |
| -first branch would be in canonical form, the second branch not since the |
37 |
| -occurring DeBruijn index `1` could be replaced with `0`. |
38 |
| - |
39 |
| -## Clause |
40 |
| -In the A clause is the disjunction of several expressions. For example the clause |
41 |
| -`condition_1 || condition_2 || ...` states that at least one of the conditions |
42 |
| -holds. |
43 |
| - |
44 |
| -There are two notable special cases of clauses. A *Horn clause* has at most one |
45 |
| -positive literal. A *Definite clause* has exactly one positive literal. |
46 |
| - |
47 |
| -*Horn clauses* can be written in the form `A || !B || !C || ...` with `A` being |
48 |
| -the optional positive literal. Due to the equivalence `(P => Q) <=> (!P || Q)` |
49 |
| -the clause can be expressed as `B && C && ... => A` which means that A is true |
50 |
| -if `B`, `C`, etc. are all true. All rules in chalk are in this form. For example |
51 |
| - |
52 |
| -``` |
53 |
| -struct A<T> {} |
54 |
| -impl<T> B for A<T> where T: C + D {} |
55 |
| -``` |
56 |
| - |
57 |
| -is expressed as the *Horn clause* `(T: C) && (T: D) => (A<T>: B)`. This formula |
58 |
| -has to hold for all values of `T`. The second example |
59 |
| - |
60 |
| -``` |
61 |
| -struct A {} |
62 |
| -impl B for A {} |
63 |
| -impl C for A {} |
64 |
| -``` |
65 |
| - |
66 |
| -is expressed as the *Horn clause* `(A: B) && (A: C)`. Note the missing |
67 |
| -consequence. |
68 |
| - |
69 |
| -## DeBruijn Index |
70 |
| -DeBruijn indices numerate literals that are bound in an unambiguous way. The |
71 |
| -literal is given the number of its binder. The indices start at zero from the |
72 |
| -innermost binder increasing from the inside out. |
73 |
| - |
74 |
| -Given the example `forall<T> { exists<U> { T: Foo<Item=U> } }` the |
75 |
| -literal names `U` and `T` are replaced with `0` and `1` respectively and the names are erased from the binders: `forall<_> |
76 |
| -{ exists<_> { 1: Foo<Item=0> } }`. |
77 |
| - |
78 |
| -## Formula |
79 |
| -A formula is a logical expression consisting of literals and constants connected |
80 |
| -by logical operators. |
81 |
| - |
82 |
| -## Goal |
83 |
| -With a set of type variables, given types, traits and impls, a goal specifies a |
84 |
| -problem which is solved by finding types for the type variables that satisfy the |
85 |
| -formula. For example the goal `exists<T> { T: u32 }` can be solved with `T = |
86 |
| -u32`. |
87 |
| - |
88 |
| -## Literal |
89 |
| -A literal is an atomic element of a formula together with the constants `true` |
90 |
| -and `false`. It is equivalent to a variable in an algebraic expressions. Note |
91 |
| -that literals are *not* the same as the type variables used in specifying a |
92 |
| -goal. |
93 |
| - |
94 |
| -## Normal form |
95 |
| -To say that a statement is in a certain *normal form* means that the pattern in |
96 |
| -which the subformulas are arranged fulfil certain rules. The individual patterns |
97 |
| -have different advantages for their manipulation. |
98 |
| - |
99 |
| -### Conjunctive normal form (CNF) |
100 |
| -A formula in CNF is a conjunction of disjunctions. For example `(x1 || x2 || |
101 |
| -x3) && (x4 || x5 || x6)` is in CNF. |
102 |
| - |
103 |
| -### Disjunctive normal form (DNF) |
104 |
| -A formula in DNF is a disjunction of conjunctions. For example `(x1 && x2 && |
105 |
| -x3) || (x4 && x5 && x6)` is in DNF. |
106 |
| - |
107 |
| -### Negation normal form (NNF) |
108 |
| -A formula in NNF consists only of literals, the connectives `&&` and `||` and |
109 |
| -`true` and `false`. |
110 |
| - |
111 |
| -### Prenex normal form (PNF) |
112 |
| -All quantifiers are on the highest level of a formula and do not occur inside |
113 |
| -the subformulas of the expression. |
114 |
| - |
115 |
| -- `forall(x). exists(y). forall(z). P(x) && P(y) => P(z)` is in PNF. |
116 |
| -- `(exists(x). P(x)) => exists(y). P(y) && forall(z). P(z)` is *not* in PNF. |
117 |
| - |
118 |
| -## Normalization |
119 |
| -Normalization is the process of converting an associated type to a concrete |
120 |
| -type. In the case of an iterator this would mean that the associated `Item` type |
121 |
| -is replaced with something more meaningful with respect to the individual |
122 |
| -context (e.g. `u32`). |
123 |
| - |
124 |
| -## Projection |
125 |
| -Projection is the reference to a field or (in the context of Rust) to a type |
126 |
| -from another type. |
127 |
| - |
128 |
| -## Satisfiability |
129 |
| -A formula is satisfiable iff there is a valuation for the atoms inside the |
130 |
| -formula that makes it true. |
131 |
| - |
132 |
| -## Unification |
133 |
| -Unification is the process of solving a formula. That means unification finds |
134 |
| -values for all the free literals of the formula that satisfy it. In the context |
135 |
| -of chalk the values refer to types. |
136 |
| - |
137 |
| -## Universe |
138 |
| -A universe sets the scope in which a particular variable name is bound. (See |
139 |
| -*Binder*.) A universe can encapsulate other universes. A universe can |
140 |
| -be contained by only one parent universe. Universes have therefore a tree-like |
141 |
| -structure. A universe can access the variable names of itself and the parent |
142 |
| -universes but not of the sibling universes. |
143 |
| - |
144 |
| -## Well-formed |
145 |
| -A formula is well-formed if it is constructed according to a predefined set of |
146 |
| -syntactic rules. |
147 |
| - |
148 |
| -In the context of the Rust type system this means that basic rules for type |
149 |
| -construction have to be met. Two examples: 1) Given a struct definition |
150 |
| - |
151 |
| -```rust |
152 |
| -struct HashSet<T: Hash> |
153 |
| -``` |
154 |
| -then a type `HashSet<i32>` is well-formed since `i32` implements `Hash`. A type |
155 |
| -`HashSet<NoHash>` with a type `NoHash` that does not implement the `Hash` trait |
156 |
| -is not well-formed. |
157 |
| - |
158 |
| -2) If a trait demands by its definition the implementation of further traits |
159 |
| -for a certain type then these secondary traits have to be implemented as well. |
160 |
| -If a type `Foo` implements `trait Eq: PartialEq` then this type has to implement |
161 |
| -`trait PartialEq` as well. If it does not, then the type `Foo: Eq` is not well |
162 |
| -formed according to Rust type building rules. |
163 |
| - |
164 |
| -## Quantifier |
165 |
| - |
166 |
| -### Existential quantifier |
167 |
| -A formula with the existential quantifier `exists(x). P(x)` is satisfiable if |
168 |
| -and only if there exists at least one value for all possible values of x which |
169 |
| -satisfies the subformula `P(x)`. |
170 |
| - |
171 |
| -In the context of chalk, the existential quantifier usually demands the |
172 |
| -existence of exactly one instance (i.e. type) that satisfies the formula (i.e. |
173 |
| -type constraints). More than one instance means that the result is ambiguous. |
174 |
| - |
175 |
| -### Universal quantifier |
176 |
| -A formula with the universal quantifier `forall(x). P(x)` is satisfiable |
177 |
| -if and only if the subformula `P(x)` is true for all possible values for x. |
178 |
| - |
179 |
| -### Helpful equivalences |
180 |
| -- `not(forall(x). P(x)) <=> exists(x). not(P(x))` |
181 |
| -- `not(exists(x). P(x)) <=> forall(x). not(P(x))` |
182 |
| - |
183 |
| -## Skolemization |
184 |
| -Skolemization is a technique of transferring a logical formula with existential |
185 |
| -quantifiers to a statement without them. The resulting statement is in general |
186 |
| -not equivalent to the original statement but equisatisfiable. |
187 |
| - |
188 |
| -## Validity |
189 |
| -An argument (*premise* therefore *conclusion*) is valid iff there is no |
190 |
| -valuation which makes the premise true and the conclusion false. |
191 |
| - |
192 |
| -Valid: `A && B therefore A || B`. Invalid: `A || B therefore A && B` because the |
193 |
| -valuation `A = true, B = false` makes the premise true and the conclusion false. |
194 |
| - |
195 |
| -## Valuation |
196 |
| -A valuation is an assignment of values to all variables inside a logical |
197 |
| -formula. |
198 |
| - |
199 |
| -# Literature |
200 |
| -- Offline |
201 |
| - - "Introduction to Formal Logic", Peter Smith |
202 |
| - - "Handbook of Practical Logic and Automated Reasoning", John Harrison |
203 |
| - - "Types and Programming Languages", Benjamin C. Pierce |
| 3 | +Please see [Appendix A: Glossary and terminology](`http://rust-lang.github.io/chalk/book/glossary.html`) in Chalk book. |
0 commit comments