Make minor edits to part 5 of SPA
Signed-off-by: Danila Fedorin <danila.fedorin@gmail.com>
This commit is contained in:
parent
697f083237
commit
d94ceeab2e
|
@ -9,7 +9,7 @@ draft: true
|
||||||
|
|
||||||
In the previous several posts, I've formalized the notion of lattices, which
|
In the previous several posts, I've formalized the notion of lattices, which
|
||||||
are an essential ingredient to formalizing the analyses in Anders Møller's
|
are an essential ingredient to formalizing the analyses in Anders Møller's
|
||||||
lecutre notes. However, there can be no program analysis without a program
|
lecture notes. However, there can be no program analysis without a program
|
||||||
to analyze! In this post, I will define the (very simple) language that we
|
to analyze! In this post, I will define the (very simple) language that we
|
||||||
will be analyzing. An essential aspect of the language is its
|
will be analyzing. An essential aspect of the language is its
|
||||||
[semantics](https://en.wikipedia.org/wiki/Semantics_(computer_science), which
|
[semantics](https://en.wikipedia.org/wiki/Semantics_(computer_science), which
|
||||||
|
@ -40,9 +40,9 @@ This time, the English interpretation of the rule is as follows:
|
||||||
> then to evaluate the statement, you evaluate its `then` branch.
|
> then to evaluate the statement, you evaluate its `then` branch.
|
||||||
|
|
||||||
These rules are certainly not equivalent. For instance, the former allows
|
These rules are certainly not equivalent. For instance, the former allows
|
||||||
the "then" branch to be executed when the condition is `2` two; however, in
|
the "then" branch to be executed when the condition is `2`; however, in
|
||||||
the latter, the value of the conditional must be `1`. If our analysis were
|
the latter, the value of the conditional must be `1`. If our analysis were
|
||||||
_flow-sensitive_ (our first few will not be), then this difference would change
|
intelligent (our first few will not be), then this difference would change
|
||||||
its output when determining the signs of the following program:
|
its output when determining the signs of the following program:
|
||||||
|
|
||||||
```
|
```
|
||||||
|
@ -58,7 +58,7 @@ Using the first, more "relaxed" rule, the condition would be considered "true",
|
||||||
and the sign of `y` would be `-`. On the other hand, using the second,
|
and the sign of `y` would be `-`. On the other hand, using the second,
|
||||||
"stricter" rule, the sign of `y` would be `+`. I stress that in this case,
|
"stricter" rule, the sign of `y` would be `+`. I stress that in this case,
|
||||||
I am showing a flow-sensitive analysis (one that can understand control flow
|
I am showing a flow-sensitive analysis (one that can understand control flow
|
||||||
and make more speciifc predictions); for our simplest analyses, we will not
|
and make more specific predictions); for our simplest analyses, we will not
|
||||||
be aiming for flow-sensitivity. There is plenty of work to do even then.
|
be aiming for flow-sensitivity. There is plenty of work to do even then.
|
||||||
|
|
||||||
The point of showing these two distinct rules is that we need to be very precise
|
The point of showing these two distinct rules is that we need to be very precise
|
||||||
|
@ -137,7 +137,7 @@ it prints its argument to the console!
|
||||||
For the formalization, it turns out to be convenient to separate "simple"
|
For the formalization, it turns out to be convenient to separate "simple"
|
||||||
statements from "complex" ones. Pragmatically speaking, the difference is that
|
statements from "complex" ones. Pragmatically speaking, the difference is that
|
||||||
between the "simple" and the "complex" is control flow; simple statements
|
between the "simple" and the "complex" is control flow; simple statements
|
||||||
will be guaranteed to always execute one-by-one, without any decisions or jumps.
|
will be guaranteed to always execute without any decisions or jumps.
|
||||||
The reason for this will become clearer in subsequent posts; I will foreshadow
|
The reason for this will become clearer in subsequent posts; I will foreshadow
|
||||||
a bit by saying that consecutive simple statements can be placed into a single
|
a bit by saying that consecutive simple statements can be placed into a single
|
||||||
[basic block](https://en.wikipedia.org/wiki/Basic_block).
|
[basic block](https://en.wikipedia.org/wiki/Basic_block).
|
||||||
|
@ -151,7 +151,7 @@ noop
|
||||||
```
|
```
|
||||||
|
|
||||||
These will always be executed in the same order, exactly once. Here, `noop`
|
These will always be executed in the same order, exactly once. Here, `noop`
|
||||||
is a conveneint type of statement that simply does nothing.
|
is a convenient type of statement that simply does nothing.
|
||||||
|
|
||||||
On the other hand, the following statement is not simple:
|
On the other hand, the following statement is not simple:
|
||||||
|
|
||||||
|
@ -161,7 +161,7 @@ while x {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
it's not simple because it makes decisions about how the code should be executed;
|
It's not simple because it makes decisions about how the code should be executed;
|
||||||
if `x` is nonzero, it will try executing the statement in the body of the loop
|
if `x` is nonzero, it will try executing the statement in the body of the loop
|
||||||
(`x = x - 1`). Otherwise, it would skip evaluating that statement, and carry on
|
(`x = x - 1`). Otherwise, it would skip evaluating that statement, and carry on
|
||||||
with subsequent code.
|
with subsequent code.
|
||||||
|
@ -171,12 +171,12 @@ I first define simple statements using the `BasicStmt` type:
|
||||||
{{< codelines "Agda" "agda-spa/Language/Base.agda" 18 20 >}}
|
{{< codelines "Agda" "agda-spa/Language/Base.agda" 18 20 >}}
|
||||||
|
|
||||||
Complex statements are just called `Stmt`; they include loops, conditionals and
|
Complex statements are just called `Stmt`; they include loops, conditionals and
|
||||||
sequences (
|
sequences ---
|
||||||
{{< sidenote "right" "then-note" "\(s_1\ \text{then}\ s_2\)" >}}
|
{{< sidenote "right" "then-note" "\(s_1\ \text{then}\ s_2\)" >}}
|
||||||
The standard notation for sequencing in imperative languages is
|
The standard notation for sequencing in imperative languages is
|
||||||
\(s_1; s_2\). However, Agda gives special meaning to the semicolon,
|
\(s_1; s_2\). However, Agda gives special meaning to the semicolon,
|
||||||
and I couldn't find any passable symbolic alternatives.
|
and I couldn't find any passable symbolic alternatives.
|
||||||
{{< /sidenote >}} is a sequence where \(s_2\) is evaluated after \(s_1\)).
|
{{< /sidenote >}} is a sequence where \(s_2\) is evaluated after \(s_1\).
|
||||||
Complex statements subsume simple statements, which I model using the constructor
|
Complex statements subsume simple statements, which I model using the constructor
|
||||||
`⟨_⟩`.
|
`⟨_⟩`.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user