11========================================================================
2- Tactic: `` proc ` `
2+ Tactic: `proc `
33========================================================================
44
5- The `` proc ` ` tactic applies to program-logic goals where the procedure(s)
5+ The `proc ` tactic applies to program-logic goals where the procedure(s)
66under consideration are referred to by name rather than content. It is
77typically the first tactic applied when reasoning about procedure calls
88or top level program logic statements.
99
10- There are two variants of the `` proc ` ` tactic, depending on whether the
10+ There are two variants of the `proc ` tactic, depending on whether the
1111procedure(s) in question are abstract (i.e., declared but not defined)
1212or concrete (i.e., defined with a body of code).
1313
1414The abstract variant is a bit different for probabilistic relational
1515Hoare logic compared to the other program logics, so we describe it
16- separately.
16+ separately. When one of the two procedures is abstract and the other is
17+ concrete the :ref: `proc* <procstar-tactic >` tactic can be used instead.
1718
1819.. contents ::
1920 :local:
@@ -24,9 +25,9 @@ Variant: Concrete procedure(s)
2425
2526.. admonition :: Syntax
2627
27- `` proc ` `
28+ `proc `
2829
29- The `` proc ` ` tactic, when applied to concrete procedures, unfolds the
30+ The `proc ` tactic, when applied to concrete procedures, unfolds the
3031procedure definition(s) at hand, replacing the procedure call(s)
3132with the body(ies) of the corresponding procedure(s). The proof goal is
3233then updated accordingly.
@@ -87,9 +88,9 @@ Variant: Abstract procedure (non-relational)
8788
8889.. admonition :: Syntax
8990
90- `` proc {formulaI} ` `
91+ `proc {formulaI} `
9192
92- Here, `` {formulaI} ` ` is an invariant that should be preserved by the
93+ Here, `{formulaI} ` is an invariant that should be preserved by the
9394procedure. The invariant can refer to global variables not being modified
9495by the procedure. To ensure that variables of interest cannot be modified,
9596it may be necessary to add restrictions to the module type of the abstract procedure, specifying which globals are not accessed.
@@ -229,34 +230,34 @@ of the procedure under consideration.
229230Variant: Abstract procedure (relational)
230231------------------------------------------------------------------------
231232
232- The relational variant of the `` proc ` ` tactic for abstract procedures
233+ The relational variant of the `proc ` tactic for abstract procedures
233234requires both procedures to be the same, though their module arguments
234235may differ.
235236
236237.. admonition :: Syntax
237238
238- - `` proc {formulaI} ` `
239- - `` proc {formulaB} {formulaI} ` `
240- - `` proc {formulaB} {formulaI} {formulaJ} ` `
239+ - `proc {formulaI} `
240+ - `proc {formulaB} {formulaI} `
241+ - `proc {formulaB} {formulaI} {formulaJ} `
241242
242243Here:
243244
244- - `` {formulaI} ` ` is a two-sided invariant that should be preserved by the
245+ - `{formulaI} ` is a two-sided invariant that should be preserved by the
245246 pair of procedures.
246- - `` {formulaB} ` ` is an optional formula representing a bad event on the
247+ - `{formulaB} ` is an optional formula representing a bad event on the
247248 right side after which the invariant need no longer hold.
248- - `` {formulaJ} ` ` is an optional formula representing the invariant after
249- the bad event has occurred. This is optional even if `` {formulaB} ` ` is
250- provided; in which case the invariant is taken to be `` true ` ` after the
249+ - `{formulaJ} ` is an optional formula representing the invariant after
250+ the bad event has occurred. This is optional even if `{formulaB} ` is
251+ provided; in which case the invariant is taken to be `true ` after the
251252 bad event.
252253
253254The tactic can be thought of as keeping both procedures in sync using
254- `` {formulaI} `` until the bad event `` {formulaB} ` ` occurs on the right
255- side, after which they are no longer kept in sync. Instead `` {formulaJ} ` `
255+ `{formulaI} ` until the bad event `{formulaB} ` occurs on the right
256+ side, after which they are no longer kept in sync. Instead `{formulaJ} `
256257is then preserved by the left and right procedures individually, no matter
257258the order in which the two sides make progress.
258259
259- When only `` {formulaI} ` ` is provided, the tactic works similarly to the
260+ When only `{formulaI} ` is provided, the tactic works similarly to the
260261non-relational variants, generating proof obligations to ensure that
261262the invariant, equality of the globals of the module containing the
262263procedure and equality of arguments holds and that equality of the
@@ -314,30 +315,30 @@ and yield equal results when called on equal arguments.
314315 ( * Procedure g2 preserves invariant *)
315316 abort.
316317
317- When `` {formulaB} `` and `` {formulaJ} ` ` are provided, the equality of
318- arguments, results, globals and `` {formulaI} ` ` obligations are modified to
318+ When `{formulaB} ` and `{formulaJ} ` are provided, the equality of
319+ arguments, results, globals and `{formulaI} ` obligations are modified to
319320only hold/need to hold conditional on the bad event not having occurred on
320321the right side. When the bad event has occurred, we instead require that
321- `` {formulaJ} ` ` holds without any additional equality requirements. Since
322+ `{formulaJ} ` holds without any additional equality requirements. Since
322323the behavior of the two sides is no longer synchronized after the bad
323324event, an obligation is generated to ensure that the procedure is lossless
324325when the procedures in its module arguments are lossless, to avoid the
325326weights diverging after the bad event.
326327
327328For every procedure of every module argument to the abstract procedure on
328329the left, an additional proof obligation is generated to ensure that the
329- when the bad event has happened and `` {formulaJ} ` ` holds for some right
330+ when the bad event has happened and `{formulaJ} ` holds for some right
330331memory, then it is guaranteed to still hold for that right memory after
331332running the procedure of the argument on the left. Similarly, for every
332333procedure of every module argument to the abstract procedure on the right,
333334an additional proof obligation is generated to ensure that when the bad
334- event has happened and `` {formulaJ} ` ` holds for some left memory, then the
335- bad event on the right and the two-sided invariant `` {formulaJ} ` ` is
335+ event has happened and `{formulaJ} ` holds for some left memory, then the
336+ bad event on the right and the two-sided invariant `{formulaJ} ` is
336337guaranteed to still hold for the left memory after running the procedure
337338of the argument on the right.
338339
339340If you want the bad event to be on the left side instead, you can swap the
340- two programs using the `` sym `` tactic before applying `` proc ` `.
341+ two programs using the `sym ` tactic before applying `proc `.
341342
342343.. ecproof ::
343344 :title: Probabilistic Relational Hoare logic example with bad event
0 commit comments