Web-Projects/blog-static
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Move original 'monotone function' text into new post and heavily rework it

Browse Source 
Signed-off-by: Danila Fedorin <danila.fedorin@gmail.com>
This commit is contained in:
Danila Fedorin
2024-05-12 18:28:44 -07:00
parent 2b5dcf12d7
commit a20fe07a56
2 changed files with 325 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
content/blog/00_spa_agda_intro.md
View File

@@ -1,6 +1,7 @@
---
title: "Implementing and Verifying \"Static Program Analysis\" in Agda, Part 0: Intro"
series: "Static Program Analysis in Agda"
description: "In this post, I give a top-level overview of my work on formally verified static analyses"
date: 2024-04-12T14:23:03-07:00
draft: true
---
@@ -86,81 +87,3 @@ for a post or two:
{{< todo >}}
Once the posts are ready, link them here to add some kind of navigation.
{{< /todo >}}
### Monotone Frameworks
I'll start out as abstractly and vaguely as possible. In general, the sorts of
analyses I'll be formalizing are based on _monotone frameworks_.
The idea with monotone frameworks is to rank information about program state
using some kind of _order_. Intuitively, given two pieces of "information",
one is less than another if it's more specific. Thus, "`x` has a positive sign"
is less than "`x` has any sign", since the former is more specific than the latter.
The sort of information that you are comparing depends on the analysis. In all
cases, the analysis itself is implemented as a function that takes the "information
so far", and updates it based on the program, producing "updated information so far".
Not all such functions are acceptable; it's possible to write an "updater function"
that keeps slightly adjusting its answer. Such a function could keep running
forever, which is a little too long for a program analyzer. We need something
to ensure the analysis ends.
There are two secret ingredients to ensure that an analysis terminates.
The first is a property called _monotonicity_; a function is monotonic if
it preserves the order between its inputs. That is, if you have two pieces of
information `x1` and `x2`, with `x1 <= x2`, then `f(x1) <= f(x2)`. The second
property is that our "information" has a _finite height_. Roughly, this means
that if you tried to arrange pieces of information in a line, from least to
greatest, your line could only get so long. Combined, this leads to the
following property (I'm being reductive here while I give an overview):
_With a monotoninc function and a finite-height order, if you start at the
bottom, each invocation of the function moves you up some line. Since the
line can only be so long, you're guaranteed to reach the end eventually._
The above three-paragraph explanation omits a lot of details, but it's a start.
To get more precise, we must drill down into several aspects of what I've
said so far. The first of them is, __how can we compare program states using
an order?__
### Lattices
The "information" we'll be talking about will form an algebraic structure
called a [lattice](https://en.wikipedia.org/wiki/Lattice_(order)). Algebraically,
a lattice is simply a set with two binary operations on it. Unlike the familiar
`+`, `-`, and `*` and `/`, the binary operations on a lattice are called
"join" and "meet", and are written as `⊔` and `⊓`. Intuitively, they correspond
to "take the maximum of two values" and "take the minimum of two values". That
may not be all that surprising, since it's the order of values that we care about.
Continuing the analogy, let's talk some properties of "minimum" and "maximum",
* \\(\\max(a, a) = \\min(a, a) = a\\). The minimum and maximum of one number is
just that number. Mathematically, this property is called _idempotence_.
* \\(\\max(a, b) = \\max(b, a)\\). If you're taking the maximum of two numbers,
it doesn't matter much one you consider first. This property is called
_commutativity_.
* \\(\\max(a, \\max(b, c)) = \\max(\\max(a, b), c)\\). When you have three numbers,
and you're determining the maximum value, it doesn't matter which pair of
numbers you compare first. This property is called _associativity_.
All of the properties of \\(\\max\\) also hold for \\(\\min\\). There are also
a couple of facts about how \\(\\max\\) and \\(\\min\\) interact _with each other_.
They are usually called the _absorption laws_:
* \\(\\max(a, \\min(a, b)) = a\\). This one is a little less obvious; \\(a\\)
is either less than or bigger than \\(b\\); so if you try to find the maximum
__and__ the minimum of \\(a\\) and \\(b\\), one of the operations will return
\\(a\\).
* \\(\\min(a, \\max(a, b)) = a\\). The reason for this one is the same as
the reason above.
Lattices model a specific kind of order; their operations are meant to
generalize \\(\\min\\) and \\(\\max\\). Thus, to make the operations behave
as expected (i.e., the way that \\(\\min\\) and \\(\\max\\) do), they are
required to have all of the properties we've listed so far. We can summarize
the properties in table.
| Property Name | Definition |
|---------------|:----------------------------------------------------:|
| Idempotence | {{< latex >}}\forall x. x \sqcup x = x{{< /latex >}}<br>{{< latex >}}\forall x. x \sqcap x = x{{< /latex >}} |
| Commutativity | {{< latex >}}\forall x, y. x \sqcup y = y \sqcup x{{< /latex >}}<br>{{< latex >}}\forall x, y. x \sqcap y = y \sqcap x{{< /latex >}} |
| Associativity | {{< latex >}}\forall x, y, z. x \sqcup (y \sqcup z) = (x \sqcup y) \sqcup z{{< /latex >}}<br>{{< latex >}}\forall x, y, z. x \sqcap (y \sqcap z) = (x \sqcap y) \sqcap z{{< /latex >}} |
| Absorption Laws | {{< latex >}}\forall x, y. x \sqcup (x \sqcap y) = x{{< /latex >}}<br>{{< latex >}}\forall x, y. x \sqcap (x \sqcup y) = x{{< /latex >}}