Skip to content

Commit

Permalink
remove inlining
Browse files Browse the repository at this point in the history
  • Loading branch information
gottschali committed Jan 29, 2025
1 parent df91faa commit 83d6894
Showing 1 changed file with 1 addition and 2 deletions.
3 changes: 1 addition & 2 deletions src/pure.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,6 @@ Now if `Cube` were nondeterministic, the calls `Cube(2)` and `Cube(2)` with the
Hypothetically, if we could call non-deterministic functions in proof annotations, the verification verdict would become nondeterministic in turn.
This is clearly undesirable; the same program shall either verify or not.
To be precise, specifications are not executed like normal Go code, so we could not simply run a nondeterministic function and use its output.
A call to a pure function is best thought as inlining the function, with the parameters substituted.
The arguments might not be concrete, as in the above example, where we assert `Cube(n) >= 0` for an arbitrary positive integer `n`.

If `Cube` had side-effects, `assert Cube(2) == 8` and `assert Cube(2) >= 8 && Cube(2) <= 8` could again not be treated as equivalent.
Expand Down Expand Up @@ -172,7 +171,7 @@ func fibonacci(n int) (res int) {

## Pure functions are transparent
Unlike normal functions, where we cannot peek inside their body,
calls to `pure` functions can be thought of as inlined.
Gobra learns the body of `pure` functions when calling them.
The following assertions pass, without having specified a postcondition.
``` go
func client1(n int) {
Expand Down

0 comments on commit 83d6894

Please sign in to comment.