In the previous post, I introduced the class of finite-height lattices:
lattices where chains made from elements and the less-than operator <
can only be so long. As a first example,
natural numbers form a lattice,
but they are not a finite-height lattice; the following chain can be made
infinitely long:
There isn’t a “biggest natural number”! On the other hand, we’ve seen that our sign lattice has a finite height; the longest chain we can make is three elements long; I showed one such chain (there are many chains of three elements) in the previous post, but here it is again:
It’s also true that the Cartesian product lattice has a finite height, as long as and are themselves finite-height lattices. In the specific case where both and are the sign lattice () we can observe that the longest chains have five elements. The following is one example:
The fact that and are themselves finite-height lattices is important; if either one of them is not, we can easily construct an infinite chain of the products. If we allowed to be natural numbers, we’d end up with infinite chains like this one:
Another lattice that has a finite height under certain conditions is the map lattice. The “under certain conditions” part is important; we can easily construct an infinite chain of map lattice elements in general:
As long as we have infinite keys to choose from, we can always keep
adding new keys to make bigger and bigger maps. But if we fix the keys in
the map — say, we use only a
and b
— then suddenly our heights are once
again fixed. In fact, for the two keys I just picked, one longest chain
is remarkably similar to the product chain above.
The class of finite-height lattices is important for static program analysis, because it ensures that out our analyses don’t take infinite time. Though there’s an intuitive connection (“finite lattices mean finite execution”), the details of why the former is needed for the latter are nuanced. We’ll talk about them in a subsequent post.
In the meantime, let’s dig deeper into the notion of finite height, and the Agda proofs of the properties I’ve introduced thus far.
Formalizing Finite Height
The formalization I settled on is quite similar to the informal description:
a lattice has a finite height of length if the longest chain
of elements compared by is exactly . There’s only a slight
complication: we allow for equivalent-but-not-equal elements in lattices.
For instance, for a map lattice, we don’t care about the order of the keys:
so long as two maps relate the same set of keys to the same respective values,
we will consider them equal. This, however, is beyond the notion of Agda’s
propositional equality (_≡_
). Thus, we we need to generalize the definition
of a chain to support equivalences. I parameterize the Chain
module
in my code by an equivalence relation, as well as the comparison relation R
,
which we will set to <
for our chains. The equivalence relation _≈_
and the
ordering relation R
/<
are expected to play together nicely (if a < b
, and
a
is equivalent to c
, then it should be the case that c < b
).
From there, the definition of the Chain
data type is much like the definition
of a vector from Data.Vec
,
but indexed by the endpoints, and containing witnesses of R
/<
between its elements. The indexing allows for representing
the type of chains between particular lattice elements, and serves to ensure
concatenation and other operations don’t merge disparate chains.
In the done
case, we create a single-element chain, which has no comparisons.
In this case, the chain starts and stops at the same element (where “the same”
is modulo our equivalence). The step
case prepends a new comparison a1 < a2
to an existing chain; once again, we allow for the existing chain to start
with a different-but-equivalent element a2'
.
With that definition in hand, I define what it means for a type of
chains between elements of the lattice A
to be bounded by a certain height; simply
put, all chains must have length less than or equal to the bound.
Though Bounded
specifies a bound on the length of chains, it doesn’t
specify the (lowest) bound. Specifically, if the chains can only have
length three, they are bounded by both 3, 30, and 300. To claim a lowest
bound (which would be the maximum length of the lattice), we need to show that
a chain of that length actually exists (otherwise,
we could take the previous natural number, and it would be a bound as well).
Thus, I define the Height
predicate to require that a chain of the desired
height exists, and that this height bounds the length of all other chains.
Finally, for a lattice to have a finite height, the type of chains formed by using
its less-than operator needs to have that height (satisfy the Height h
predicate).
To avoid having to thread through the equivalence relation, congruence proof,
and more, I define a specialized predicate for lattices specifically.
I do so as a “method” in my IsLattice
record.
|
|
Thus, bringing the operators and other definitions of IsLattice
into scope
will also bring in the FixedHeight
predicate.
Fixed Height of the “Above-Below” Lattice
We’ve already seen intuitive evidence that the sign lattice — which is an instance of
the “above-below” lattice —
has a fixed height. The reason is simple: we extended a set of incomparable
elements with a single element that’s greater, and a single element that’s lower.
We can’t make chains out of incomparable elements (since we can’t compare them
using <
); thus, we can only have one <
from the new least element, and
one <
from the new greatest element.
The proof is a bit tedious, but not all that complicated. First, a few auxiliary helpers; feel free to read only the type signatures. They specify, respectively:
- That the bottom element of the above-below lattice is less than any concrete value from the underlying set. For instance, in the sign lattice case, .
- That is the only element satisfying the first property; that is, any value strictly less than an element of the underlying set must be .
- That the top element of the above-below lattice is greater than any concrete value of the underlying set. This is the dual of the first property.
- That, much like the bottom element is the only value strictly less than elements of the underlying set, the top element is the only value strictly greater.
|
|
From there, we can construct an instance of the longest chain. Actually, there’s a bit of a hang-up: what if the underlying set is empty? Concretely, what if there were no signs? Then we could only construct a chain with one comparison: . Instead of adding logic to conditionally specify the length, I simply require that the set is populated by requiring a witness
I use this witness to construct the two-<
chain.
The proof that the length of two — in terms of comparisons — is the
bound of all chains of AboveBelow
elements requires systematically
rejecting all longer chains. Informally, suppose you have a chain of
three or more comparisons.
- If it starts with , you can’t add any more elements since that’s the greatest element (contradiction).
- If you start with an element of the underlying set, you could add another element, but it has to be the top element; after that, you can’t add any more (contradiction).
- If you start with , you could arrive at a chain of two comparisons, but you can’t go beyond that (in three cases, each leading to contradictions).
|
|
Thus, the above-below lattice has a length of two comparisons (or alternatively, three elements).
|
|
And that’s it.
Fixed Height of the Product Lattice
Now, for something less tedious. We saw above that for a product lattice
to have a finite height,
its constituent lattices must have a finite height.
The proof was by contradiction (by constructing an infinitely long product
chain given a single infinite lattice). As a result, we’ll focus this
section on products of two finite lattices A
and B
. Additionally, for the
proofs in this section, I require element equivalence to be decidable.
Let’s think about how we might go about constructing the longest chain in a product lattice. Let’s start with some arbitrary element . We need to find another value that isn’t equal to , because we’re building chains of the less-than operator , and not the less-than-or-equal operator . As a result, we need to change either the first component, the second component, or both. If we’re building “to the right” (adding bigger elements), the new components would need to be bigger. Suppose then that we came up with and , with and . We could then create a length-one chain:
That works, but we can construct an even longer chain by increasing only one element at a time:
We can apply this logic every time; the conclusion is that when building
up a chain, we need to increase one element at a time. Then, how many times
can we increase an element? Well, if lattice A
has a height of two (comparisons),
then we can take its lowest element, and increase it twice. Similarly, if
lattice B
has a height of three, starting at its lowest element, we can
increase it three times. In all, when building a chain of A × B
, we can
increase an element five times. Generally, the number of <
in the product chain
is the sum of the numbers of <
in the chains of A
and B
.
This gives us a recipe for constructing
the longest chain in the product lattice: take the longest chains of A
and
B
, and start with the product of their lowest elements. Then, increase
the elements one at a time according to the chains. The simplest way to do
that might be to increase by all elements of the A
chain, and then
by all of the elements of the B
chain (or the other way around). That’s the
strategy I took when constructing the
chain above.
To formalize this notion, a few lemmas. First, given two chains where one starts with the same element another ends with, we can combine them into one long chain.
More interestingly, given a chain of comparisons in one lattice, we are able to lift it into a chain in another lattice by applying a function to each element. This function must be monotonic, because it must not be able to reverse such that . Moreover, this function should be injective, because if , then a chain might be collapsed into , changing its length. Finally, the function needs to produce equivalent outputs when giving equivalent inputs. The result is the following lemma:
|
|
Given this, and two lattices of finite height, we construct the full product
chain by lifting the A
chain into the product via ,
lifting the B
chain into the product via , and
concatenating the results. This works because the first chain ends with
, and the second starts with it.
|
|
This gets us the longest chain; what remains is to prove that this chain’s
length is the bound of all other changes. To do so, we need to work in
the opposite direction; given a chain in the product lattice, we need to
somehow reduce it to chains in lattices A
and B
, and leverage their
finite height to complete the proof.
The key idea is that for every two consecutive elements in the product lattice
chain, we know that at least one of their components must’ve increased.
This increase had to come either from elements in lattice A
or in lattice B
.
We can thus stick this increase into an A
-chain or a B
-chain, increasing
its length. Since one of the chains grows with every consecutive pair, the
number of consecutive pairs can’t exceed the combined lengths of the A
and B
chains.
I implement this idea as an unzip
function, which takes a product chain
and produces two chains made from its increases. By the logic we’ve described,
the length two chains has to bound the main one’s. I give the signature below,
and will put the implementation in a collapsible detail block. One last
detail is that the need to decide which chain to grow — and thus which element
has increased — is what introduces the need for decidable equality.
(Click here for the implementation of unzip
)
|
|
Having decomposed the product chain into constituent chains, we simply combine
the facts that they have to be bounded by the height of the A
and B
lattices,
as well as the fact that they bound the combined chain.
|
|
This completes the proof!
Iterated Products
The product lattice allows us to combine finite height lattices into a new finite height lattice. From there, we can use this newly created lattice as a component of yet another product lattice. For instance, if we had , we can take a product of that with again, and get . Since this also creates a finite-height lattice, we can repeat this process, and keep taking a product with , creating:
I call this the iterated product lattice. Its significance will become clear shortly; in the meantime, let’s prove that it is indeed a lattice (of finite height). To create an iterated product lattice, we still need two constituent lattices as input.
At a high level, the proof goes by induction on the number of applications
of the product. There’s just one trick. I’d like to build up an isLattice
instance even if A
and B
are not finite-height. That’s because in
that case, the iterated product is still a lattice, just not one with
a finite height. On the other hand, the isFiniteHeightLattice
proof
requires the isLattice
proof. Since we’re building up by induction,
that means that every recursive invocation of the function, we need
to get the “partial” lattice instance and give it to the “partial” finite
height lattice instance. When I implemented the inductive proof for
isLattice
independently from the (more specific) inductive proof
of isFiniteHeightLattice
, Agda could not unify the two isLattice
instances (the “actual” one and the one that serves as witness
for isFiniteHeightLattice
). This led to some trouble and inconvenience,
and so, I thought it best to build the two up together.
To build up with the lattice instance and — if possible — the finite height instance, I needed to allow for the constituent lattices being either finite or infinite. I supported this by defining a helper type:
|
|
Then, I defined the “everything at once” type, in which, instead of a field for the proof of finite height, has a field that constructs this proof if the necessary additional information is present.
|
|
Finally, the proof by induction. It’s actually relatively long, so I’ll include it as a collapsible block.
(Click here to expand the inductive proof)
Fixed Height of the Map Lattice
We saw above that we can make a map lattice have a finite height if we fix its keys. How does this work? Well, if the keys are always the same, we can think of such a map as just a tuple, with as many element as there are keys.
This is why I introduced iterated products earlier; we can use them to construct the second lattice in the example above. I’ll take one departure from that example, though: I’ll “pad” the tuples with an additional unit element at the end. The unit type (denoted ) — which has only a single element — forms a finite height lattice trivially; I prove this in an appendix below. Using this padding helps reduce the number of special cases; without the adding, the tuple definition might be something like the following:
On the other hand, if we were to allow the extra padding, we could drop the definition down to:
And so, we drop from two to three cases, which means less proof work for us. The tough part is to prove that the two representations of maps — the key-value list and the iterated product — are equivalent. We will not have much trouble proving that they’re both lattices (we did that last time, for both products and maps). Instead, what we need to do is prove that the height of one lattice is the same as the height of the other. We prove this by providing something like an isomorphism: a pair of functions that convert between the two representations, and preserve the properties and relationships (such as ) of lattice elements. In fact, the list of the conversion functions’ properties is quite extensive:
|
|
-
First, the functions must preserve our definition of equivalence. Thus, if we convert two equivalent elements from the list representation to the tuple representation, the resulting tuples should be equivalent as well. The reverse must be true, too.
-
Second, the functions must preserve the binary operations — see also the definition of a homomorphism. Specifically, if is a conversion function, then the following should hold:
For the purposes of proving that equivalent maps have finite heights, it turns out that this property need only hold for the join operator .
-
Finally, the functions must be inverses of each other. If you convert a list to a tuple, and then the tuple back into a list, the resulting value should be equivalent to what we started with. In fact, they need to be both “left” and “right” inverses, so that both and .
Given this, the high-level proof is in two parts:
-
Proving that a chain of the same height exists in the second (e.g., tuple) lattice: To do this, we want to take the longest chain in the first (e.g. key-value list) lattice, and convert it into a chain in the second. The mechanism for this is not too hard to imagine: we just take the original chain, and apply the conversion function to each element.
Intuitively, this works because of the structure-preserving properties we required above. For instance (recall the definition of given by Lars Hupel, which in brief is ):
-
Proving that longer chains can’t exist in the second (e.g., tuple) lattice: we’ve already seen the mechanism to port a chain from one lattice to another lattice, and we can use this same mechanism (but switching directions) to go in reverse. If we do that, we can take a chain of questionable length in the tuple lattice, port it back to the key-value map, and use the (already known) fact that its chains are bounded to conclude the same thing about the tuple chain.
As you can tell, the chain porting mechanism is doing the heavy lifting here. It’s relatively easy to implement given the conditions we’ve set on conversion functions, in both directions:
|
|
With that, we can prove the second lattice’s finite height:
|
|
The conversion functions are also not too difficult to define. I give
them below, but I refrain from showing proofs of the more involved
properties (such as the fact that from
and to
are inverses, preserve
equivalence, and distribute over join) here. You can view them by clicking
the link at the top of the code block below.
|
|
Above, FiniteValueMap ks
is the type of maps whose keys are fixed to
ks
; defined as follows:
Proving the remaining properties (which as I mentioned, I omit from the main body of the post) is sufficient to apply the isomorphism, proving that maps with finite keys are of a finite height.
Using the Finite Height Property
Lattices having a finite height is a crucial property for the sorts of static program analyses I’ve been working to implement. We can create functions that traverse “up” through the lattice, creating larger values each time. If these lattices are of a finite height, then the static analyses functions can only traverse “so high”. Under certain conditions, this guarantees that our static analysis will eventually terminate with a fixed point. Pragmatically, this is a state in which running our analysis does not yield any more information.
The way that the fixed point is found is called the fixed point algorithm. We’ll talk more about this in the next post.
Appendix: The Unit Lattice
The unit lattice is a relatively boring one. I use the built-in unit type
in Agda, which (perhaps a bit confusingly) is represented using the symbol ⊤
.
It only has a single constructor, tt
.
|
|
The equivalence for the unit type is just propositional equality (we have
no need to identify unequal values of ⊤
, since there is only one value).
Both the join and meet operations are trivially defined;
in both cases, they simply take two tt
s and produce a new tt
.
Mathematically, one might write this as .
In Agda:
These operations are trivially associative, commutative, and idempotent.
That’s sufficient for them to be semilattices:
|
|
The absorption laws are also trivially satisfied, which means that the unit type forms a lattice.
|
|
Since there’s only one element, it’s not really possible to have chains that contain any more than one value. As a result, the height (in comparisons) of the unit lattice is zero.
|
|