1.2 Relationship
A relationship is a collection whose elements are composed of ordered pairs. For example, we can define the ≡ relationship so that each element matches itself:
For the binary relationship of ≡ , we usually write 〈a, a〉∈≡ as a ≡ a:
or even simpler:
once we understand the definition of ≡ , You will find that this relationship is reflexive, symmetrical and transitive.
If a relationship is reflexive, symmetric, and transitive, then it is an equivalence relationship.
An r- relation is defined as follows , which is neither reflexive, nor symmetrical, and transitive.
We can define a new relationship ) (r , by adding a constraint to make ) (r reflexive:
this new relationship is a reflexive closure of the r relationship. In the same way, we can also define another Relationship, make it symmetrical and transferable.
This ≈r relationship is ) ( the symmetry-transitive closure of the r relationship , which is the reflexive-symmetric-transitive closure of the r relationship.
1.3 The relationship as an assignment
The above about the relationship between set B (see the previous article) and r should let you know that programming languages can be defined by text and relationships-or more specifically, by a set B and the relationship r on the set.
In fact, you might suspect that B is a Boolean expression syntax with • as "or", and ≈r represents a pair of expressions with the same Boolean value.
Indeed, using the above constraints, we can prove that (f•t)≈r(t•t) is like false v true = true v true .
However, it does not directly indicate that • is consistent with or in Boolean . On the contrary, we must prove the generality of • , that is, for any expression of B1 , (B1•t)≈rt can be established. (The result is that we can't do this, you will know in a while)
In other words, there are usually some gaps between the programming language defined by the meta-language interpreter and the language we want to ensure that it is correct. For various reasons, the properties of the language are as important as the value being calculated. For example, if • really behaves like "or", then the compiler will safely optimize **(B1•t)** to t . Similarly, if the grammatical rules of a language guarantee that a number cannot be added to any value other than another number, then the language does not need to check whether the parameter of addition is a number when implementing an adder. (Because addition can only be added to a specified value)