CS 641 Lecture -*- Outline -*-

* Overview (Back and von Wright, Ch 1)

------------------------------------------
          MAIN QUESTIONS (Ch. 1)

Problems:
 - Is a program correct,
   with respect to a specification?
 - How can we improve a program,
   while preserving correctness?

Idea:
 - Programs and specifications
   are the same thing -- contracts
   between agents


------------------------------------------
        ... So reason about contracts
        
        Mathematically this is more elegant.

------------------------------------------
        MATHEMATICAL BASIS

Higher-order logic

Lattice theory


Notation:
     A -> B           A -> B -> C
     f.x               f.a.b

------------------------------------------
        Lattice theory is also important in denotational semantics

** contracts (1.1)
*** states
   Q: what are states (\sigma) used for?
   Q: What are they made of?
        independent attributes, x_1, ..., x_n
        also called program variables

*** state space
   Q: what is a state space (\Sigma)?

   Q: What are the operations on states?
      val.x.\sigma is the value of the attribute x in state \sigma
      set.x.a.\sigma is the state that is like \sigma,
                 except that val.x.\sigma == a

*** functional update
   Q: how does an agent update the state?
      <f> : \Sigma -> \Sigma
      <f>.\sigma == f.\sigma

   Q: how do we model assignments?
         <x_i := x_i + x_j>
               maps \sigma to set.x_i.(val.x_i.\sigma + val.x_j.\sigma).\sigma

   Abuse of notation: write x_i := x_i + x_j for <x_i := x_i + x_j>

*** a language of contracts
    Q: what's the purpose of a contract?
       to "regulate the behavior of an agent"
       (a script for an actor)
    Q: what's the simplest language we could have for contracts?

------------------------------------------
       SIMPLE CONTRACTS

S ::=         "contract"
   <f>           "basic action"
 | S1 ; S2       "sequencing"
 | S1 \join S2   "alternative (free choice)"

assume that ";" binds more strongly
 than "\join"

Note that \join is the LaTeX \sqcup symbol
------------------------------------------

    We write 

    Q: how would you define a contract that does nothing to the state?
           <id> (== skip)

    Q: how would you define a contract that multiplies x by y?
    Q: that can either multiplies x by y or does nothing?
    Q: can an agent following this contract change the value of z?
    Q: does the state space have to have attributes x and y for this
       to make sense?

    Q: how would you define when an agent satisfies a contract?

    Q: why is S1; (S2; S3) == (S1; S2); S3?
    Q: why is S1 \join (S2 \join S3) == (S1 \join S2) \join S3?
    Q: is S1;S2 == S2;S1?
    Q: is S1 \join S2 == S2 \join S1?

*** cooperation between agents
    Q: how do the authors model a contract that specifies cooperation
       between two independent agents?

    By explicitly indicating for each choice, which agent gets to make it.

    Q: how would you specify a contract for me printing a file?

       me == (file := contents1 \join file := contents2); prt; ack := status
       prt == output := file; (status := 0 \join status := 1)

    Q: is our language really expressive enough for multiagent contracts?
    Q: if not, what's missing?
       assertions, and assumptions

**** assertions
     "An assertion is a requirement that an agent must satisfy in a
      given state"

      Q: how can an agent satisfy an assertion?  Not satisfy it?

      Consider:
            <f>; {x > 3}
            What property does f have to have?

            x := 1; (x := x+y; {x>1} \join x := x+z); y := x-1
            When is this satisfied? breached?

      Q: What assertion is always breached? satisfied?

      Q: How can we assign blame in a two party contract?
         indicate which party is responsible for which assertions

         x := 0;
         ((y := 1 \join_b y := 2; {false}_b); x := x_1 \join_a {false}_a);
         {y == x}_a

      Q: How does this relate to games?

**** assumptions
     Q: how does an assumption relate to a precondition?
     Q: what happens if an assumption isn't satisfied?
        the agent is released from the contract
     Q: is this realistic in real-life contracts?
        sure: assuming you have paid me $10000, I will ...

        Consider:
            [ n > 0 ]; avg := sum / n

            [ x > 0]_a; z := y - x; { z < y }_b

** Using contracts (1.2)

   we state a contract because we want to get something done
    (the postcondition)

*** Taking sides
    Normally, and programming, we look at contracts from one agent's
    perspective (a client, or an implementation).
    So we choose one side, and call it "our agent"

------------------------------------------
         TAKING SIDES (1.2)

S ::=            "contract"
   <f>              "basic action"
 | S1 ; S2          "sequencing"
 | S1 \join S2      "our choice"
 | S1 \join^o S2    "other agent's choice"
 | { g }            "our assertion"
 | { g }^o          "other's assertion"
 | [ g ]            "our assumption"
 | { g }^o          "other's assumption"


Examples

   [ x > 0]; z := y - x; { z < y }

   [ x > 0]^o; z := y - x; { z < y }^o

------------------------------------------
        Q: in which of these is our agent the server?
           the first
        Q: which one most matches the normal kind of specification of
           a procedure?
           the first
        Q: What's the other one about?

        In JML, we use "assert g" and "assume g" for { g } and [ g ].

        Q: What's the meaning of { x > y }?
        Q: What's the meaning of [ x > y ]?

        Q: If a contract is a game, when can our agent win?


        Q: What if the other agent breaches the contract?


   notation:   \sigma {| S |} q
          means that starting in initial state \sigma, our agent can satisfy
          contract S and establish postcondition q

  def (p. 7): \sigma {| S |} q holds if
  whenever (i) the assumptions that our agent makes are satisfied, and
          (ii) the other agent does not breach the contract,
  then our agent can always establish a final state that satisfies q,
  without itself breaching the contract.

  This allows our agent to satisfy the contract the matter how the
   other agent makes its choices.  (Us vs. them.)

*** generalizing to multiple agents
    Q: how can we generalize this to multiple agents?
    lump all the opponents together,
    lump all our allies together...
       so no change is needed.

*** contracts as games
    Q: if we think of this as a game, what expresses the game's rules?
       the contract

    Think of our agent as the angel, 
          our choices are thus "angelic choices"
    Think of the other agents as demons,
          their choices are thus "demonic choices"

    Q: what does it mean if the angels have a winning strategy?
       that our agent can satisfy its contract in an initial state

    Q: how can a demon lose?
       by breaching an assertion, or if we can choose an assumption
       that is false

    Q: does somebody always win this game?

       yes, they consider nontermination as losing:
       "delaying a task indefinitely is not considered to be
       acceptable way of satisfying a contract." (p. 15)

       we might make a different choice (a la Hehner),
       and include time explicitly.

** computers as agents (1.3)
    Q: what are these agents?
       computers or humans
    Q: can computers really make choices?
       yes, choices arise because of information hiding, race conditions,
            or sometimes physics (pentium chips)

    Information hiding:
         example of a set built on an array with a choose method

    Duality between client and server and between our agent and
    the other agents...
    Q: when we are programming the client, can the server's choices be
       bad for us?  How about vice versa?

** algebra of contracts (1.4)
   Q: how would you compare two contracts from the point of view of our agent?
      which is better for our agent?
            One that helps us win at least as often is at least as good.
            In terms of goals: one that helps us establish at least the same
                  goals starting from the same states.
------------------------------------------
      REFINEMENT (BIGGER IS BETTER)

def: A contract S is refined by S'
     iff for all states \sigma,
         for all predicates q,

   \sigma {| S |} q  ==> \sigma {| S' |} q

We write S \refby S' for this,
where \refby is LaTeX's \sqsubseteq symbol

------------------------------------------
        Q: Which is the better contract?
        Q: what does this have to do with Texas?

        Q: is refinement reflexive?  Transitive?
        Q: Symmetric?  Antisymmetric?   
           no, and we postulate that it is antisymmetric
        Q: so what kind of ordering is it?
           a partial ordering

        Q: what's the best possible contract from our agent's point of view?
                 [false] or {true}
        Q: the worst?
                 {false}
                 what about [true]?
        Q: so what's the least element in the contract ordering? the greatest?
           {false} and [false]

------------------------------------------
          EXAMPLES

Consider:
 (a)  x := x + 1 \join x := x + 2
 (b)  x := x + 1
 (c)                   x := x + 2

Which refine the others?



What about:
 (d)  x := x + 1 \join^o x := x + 2


------------------------------------------

   ... (a) refines both (b) and (c) and no other relationships
       i.e., (b) and (c) are refined by (a)

   ... (b) and (c) both refine (d)

------------------------------------------
          LATTICE PROPERTIES

When is the following true?

 s {| x := x + 1 \join x := x + 2 |} q

E.g., do the following hold?  why?

(x|->0){|x := x + 1 \join x := x + 2|} x==1
(x|->0){|x := x + 1 \join x := x + 2|} x==2

What if \join is replaced by \join^o?


------------------------------------------
   ...  when either  s {| x := x + 1 |} q  or  s {| x := x + 2 |} q hold
   ...  when both  s {| x := x + 1 |} q  and  s {| x := x + 2 |} q hold

   Motivation for chapter 2:
     So this defines the join (\join) and meet (\join^o == \meet)
     operations of a lattice of contracts.

     And contracts form a monoid wrt sequential composition.

     Also we can generalize to consider different state spaces,
     for this we need a category of contracts, in which the different
     state spaces are objects, and the contracts are morphisms
     (functions).

** programming constructs (1.5)

   Traditional programming constructs are simply more restrictive kinds
   of contracts that oblige an agent to carry out specific sequences
   of actions.

   Q: How would you define abort?  Skip?
      {false}, {true}

*** conditional contracts
    Q: how can we define it-then-else in terms of our current syntax?

    consider an example

             if x >= 0 then x := x + 1 else x := x + 2

        who gets to choose?
            (our agent)
            {x >= 0}; x := x + 1 \join {x < 0}; x := x + 2

        can we do this in terms of the other agent's choice?

            [x >= 0]; x := x + 1 \meet [x < 0]; x := x + 2

        is this the same? why?

    Q: how about Dijkstra's guarded conditional?
       if g1 -> S1 [] ... [] gn -> Sn fi
       == {g1 \/ ... \/ gn}; ([g1]; S1 \meet ... \meet [gn]; Sn)

       note that we don't get to choose which alternative is executed
       if several guards are true

*** recursive contracts
    Q: how could we introduce recursion into the definition of contracts?

       S ::= ... | X | (\mu X . S)

    or allow recursive definitions at top-level

      X == ...X...

    e.g., X == (y := y + 1; X \join skip)

*** iteration
    Q: can we define a while loop in terms of recursion?
       yes,
        while g do S od == (\mu X . if g then S; X else skip fi)

** specification constructs
   To make this a truly wide spectrum language we have to allow more
   abstract kinds of contracts

   Q: what way could we specify contracts more abstractly to allow
   implementations (refinements) to make more decisions?
          allow more choices
            e.g., x := 0 \meet x := 1 \meet ... \meet x := 9
          why is that meet instead of join?
            because we want to express that it's nondeterministicly chosen
          what's an implementation of this?
                    x := 1, for example, refines this

   Q: can we allow for an unbounded number of choices?
      yes, in specifications

      \meet { x := n | n >= 0 }

*** relational assignments
    generalizes functional update

------------------------------------------
        RELATIONAL ASSIGNMENT

def: Let R be a relation on states.
     Then {R} is an action such that,
     when started in a state s,
     our agent can choose a state s'
     such that s R s'.

example:
    Let R2 be the relation such that
     s R2 s'
        iff val.y.s' == val.y.s mod 2
         or val.y.s' == 50
    So (y|->3) R2 (y|->1)
    and (y|->3) R2 (y->50)

   
def: Let R be a relation on states.
     Then {R}^o, written [R]
     is an action such that,
     when started in a state s,
     the other agent can choose a state s'
     such that s R s'
------------------------------------------

   Q: when does our agent breach the contract {R} ?
      whenever there is no choice of a final state that satisfies the relation
   Q: when can our agent satisfy the contract {R}; {q} ?
      whenever there is a choice of a final state
      that satisfies the relation and also satisfies q.

   Q: when does the other agent breach the contract [R] ?
      whenever there is no choice of a final state that satisfies the relation
   Q: when does our agent satisfy the contract [R]; {q} ?
      whenever every final state that satisfies the relation satisfies q

   these are angelic and demonic update, respectively

   relational assignments/updates

   (x := n | n > x)  is a relation that
         relates s to a final state s' == set.x.n.s where n > val.x.s holds
         Note the what state the predicate is evaluated in.

   {x := n | n > x}  -- angelic, our choice

   [x := n | n > x]  -- demonic, the other agent's choice
    
   both useful as specifications

   Q: what refines the specification [y := n | n mod 2 == 0] ?
           y := 4 \meet y := 6
   Q: what refines the specification {y := n | n mod 2 == 0} ?
           {y := n | n mod 2 == 0 \/ n == 1}
           we have more choices, so this is better for us

   Q: so who is a refinement better for?
      our agent,
      so in general "a refinement decreases the number of choices
      for the other agent, and increase the number of choices for our agent."

*** pre-postcondition specifications
    From the client's point of view, the other agents is the procedure
    or specification to be called

      {x := x0 | x0 >= 0}; [r := n | n * n <= x0 /\ x0 < (n+1)*(n+1)]

    So we, the clients, get to choose a value for x,
    and the procedure gets to choose a value for r.

    From the implementation's point of view:
       [x >= 0] ; {r := n | n * n <= x /\ x < (n+1)*(n+1)}

    Note that if the client refines the first relational assignment,
    they won't be able to use the implementation.

    In general, the interaction may be more involved so that the
    choices alternate.

** correctness (1.7)
------------------------------------------
        CORRECTNESS (1.7)

def: Let p and q be predicates.
     S is correct with respect to p and q,
     written p {| S |} q,
     iff for all s that satisfy p,
         s {| S |} q holds

------------------------------------------

        Q: What ways can our agent win such a game?
                by choosing an execution that establishes the postcondition
                or leads to some of its assumptions being violated

        Q: how does this compare to total correctness?
           - it takes into account the interaction between
             our agent and the other agent (2 kinds of nondeterminism)
           - in the normal concept,
             there's nothing about breaching an assumption

*** correctness problems
------------------------------------------
          CORRECTNESS PROBLEMS

The correctness problem:
    given p, S, and q, prove p {| S |} q

The program derivation problem:
    given p and q, construct S so that
          p {| S |} q

The program analysis problem:
    given S, find p and q such that  
          p {| S |} q


The backward program derivation problem:
    given q, find S and p such that
          p {| S |} q
------------------------------------------
        also consider variants of the program analysis (reverse
        engineering) problem

        for the program derivation problems, one to find a "suitable" S,
        e.g., one that is executable, not [false]

** refinement of programs (1.8)
   Q: what is stepwise refinement?
   Q: what is program transformation?  How does it relate?

   the key idea is that refinement is defined so that preserves correctness:

       if S0 \refby Sn and p {| S0 |} q holds, then p {| Sn |} q

       so if S0 satisfies p {| S0 |} q,
          and if S0 \refby S1 \refby ... \refby Sn,
          then by transitivity, S0 \refby Sn, and so p {| Sn |} q

       we typically establish Si \refby S(i+1) by using some
       refinement law