c laus b rabrand s emantics (q1,’06) o ct 12, 2006 c laus b rabrand © 2005-2006, university of...

CLAUS BRABRAND SEMANTICS (Q1,’06) OCT 12, 2006

CLAUS BRABRAND

© 2005-2006, University of Aarhus

[ [email protected] ] [ http://www.daimi.au.dk/~brabrand/ ]

SEMANTICS (Q1,’06)

WEEK 7: ”PROGRAM EQUIVALENCE AND IMPERATIVE FEATURES”

CLAUS BRABRAND[ 2 ]

SEMANTICS (Q1,’06) OCT 12, 2006

Week 7 - Outline

Bisimulation The Bisimulation Game SOS Implementation (Interpretation) Course Evaluation Program Equivalence Imperative Blocks “The Environment-Store Model” Sketch: Various Language Extensions Other Semantic Formalisms


STRONG BISIMULATION: (~)

CLAUS BRABRAND[ 4 ]


Def: A Strong Bisimulation

Let (Proc, Act, ) be a LTS

Def: a bin. rel. R Proc Proc is a strong bisimulation iff whenever (s,t) R : aAct :

if s s’ then t t’ for some t’ such that (s’,t’) R if t t’ then s s’ for some s’ such that (s’,t’) R

Note: 1. Definition on LTS (not necessarily wrt. processes) 2. Definition relative to a (SOS) semantics (via LTS)

a

a

a

a

a

Intuition: “Only equate as consistently allowed by the semantics”

CLAUS BRABRAND[ 5 ]


Def: Strongly Bisimilar (~)

A Strong Bisimulation:

Def: a bin. rel. R Proc Proc is a strong bisimulation iff whenever (s,t) R : aAct :

if s s’ then t t’ for some t’ such that (s’,t’) R if t t’ then s s’ for some s’ such that (s’,t’) R

The Strong Bisimilarity relation (~):

Def: two (processes) s and t are strongly bisimilar( s ~ t ) iff strong bisimulation R : (s,t) R .

i.e.

a

a

a

a

‘~’ := {R | R is a strong bisimulation }

CLAUS BRABRAND[ 6 ]


Basic Properties of (~)

Theorem: ‘~’ is an equivalence relation

Theorem: ‘~’ is the largest strong bisimulation

i.e. for any bisimulation R we have that: R ‘~’

Theorem: s ~ t iff aAct :

if s s’ then t t’ for some t’ such that s’ ~ t’ if t t’ then s s’ for some s’ such that s’ ~ t’

a

a

a

a

CLAUS BRABRAND[ 7 ]


How to Prove Strong Bisimilarity ?

How to prove strong bisimilarity for two processes ?

i.e. ?:

Exhibit a (any) bisimulation R , for which:

By definition we get that: since ‘~’ was the largest bisimulation(s,t) R ‘~’

(s,t) R

p ~ q

CLAUS BRABRAND[ 8 ]


Example Proof of Bisimilarity

Example: Buffer (capacity 1):

Buffer (capacity 2):

Prove that:

A0 =def in . A1

A1 =def out . A0

B0 =def in . B1

B1 =def in . B2 + out . B0

B2 =def out . B1

B0 ~ A0|A0

B0

B1

B2

A0|A0

A1|A0 A0|A1

A1|A1

R = { (B0 , A0|A0) , (B1 , A1|A0) , (B1 , A0|A1) , (B2 , A1|A1) }

Visualizationof R

CLAUS BRABRAND[ 9 ]


How to Prove Non-Bisimilarity ?

How to prove non-bisimilarity ? i.e. ?

Enumerate all binary relations: Check that none are bisimulations and contain (p,q)

However: extremely expensive O(2|p||q|)

Use “Feynman Problem-Solving Algorithm”: (1). Write down the problem; (2). Think very hard; (3). Write down the answer.

Or…

s ~ t

CLAUS BRABRAND[ 10 ]


The Bisimulation Game

It’s Amazing…

The Bisimulation Game®

Special Family Edition (w/ TV cables & remote control) Beat your sister at Process Algebra simulation…

“Special Family Edition!”

“The Bisimulation Game”

Only$31,95

The

Bisimulation

Game


(~) BISIMULATION GAMES



The (Strong) Bisimulation Game

Let (Proc, Act, ) be a LTS and s,t Proc

Define 2-player game: [ attacker v defender ] The game is played in “rounds” and the configurations

of the game are (Proc Proc); The game starts (first round) in (s,t) Proc Proc

Intuition (objectives): The defender wants to show that: The attacker wants to show that:

a

s ~ t

s ~ t



Rules of the Bisimulation Game

In round k the players change the current configuration (sk,tk) as follows:

First, the attacker chooses: 1) one of the processes (e.g. tk); i.e., left or right; 2) a legal action from that process: a Act; 3) a legal transition according to the LTS: tk tk+1

Then, the defender chooses: -) a “counter-move” using same action, a: sk sk+1

(sk+1,tk+1) becomes the next round’s configuration…

Winning: If one player cannot make a move, the other player wins If the game is infinite (repeats configuration), the defender wins

a

a



Game Characterization of (~)

Theorem: States (processes) s and t are not strongly bisimilar

iff the attacker has a universal winning strategy States (processes) s and t are strongly bisimilar

iff the defender has a universal winning strategy

(s ~ t) basically means that: “the ‘perfect attacker’ always wins”

(s ~ t) basically means that:“the ‘perfect defender’ always wins”



Let’s Play…

Let’s play…:

~ / ~ ? show of hands…

~ ’’?

coin . (coke + sprite) coin.coke + coin.sprite ’’

coincoincoin’’

spritespritecoke

coke



Another Game…

Are the following two LTS(/processes) s and t strongly bisimilar: s ~ t ?

There’s a universal attack strategy hence, they are not strongly bisimilar : s ~ t


(~) CONGRUENCE



(~) is a Congruence for CCS

Theorem: Let P and Q be processes such that P ~ Q; then:

.P ~ .Q Act P+R ~ Q+R R Proc R+P ~ R+Q R Proc P|R ~ Q|R R Proc R|P ~ R|Q R Proc P[f] ~ Q[f] f : P(Act) P(Act) relabellings P\a ~ Q\a a Act \ { }

i.e. ‘~’ is a congruence for CCS



Other Properties of (~)

The following properties hold P, Q, R: P+Q ~ Q+P // ‘+’ commutative (P+Q)+R ~ P+(Q+R) // ‘+’ associative P|Q ~ Q|P // ‘|’ commutative (P|Q)|R ~ P|(Q|R) // ‘|’ associative P+0 ~ P // ‘0’ neutral wrt. ‘+’ P|0 ~ P // ‘0’ neutral wrt. ‘|’ ...



Summary: Strong Bisimilarity (~)

Properties of (~): an equivalence relation:

reflexive, symmetric, and transitive

the largest strong bisimulation: for proving bisimilarity (exhibit a bisimulation)

strong bisimulation game: for proving non-bisimilarity (winning attack strategy)

a congruence: P ~ Q => C[P] ~ C[Q]

obeys the following algebraic laws: ‘+’ and ‘|’ commutative, associative, and ‘0’ neutrality, …


MODEL-CHECKING



Dictionary: “model”

In this course (we use): 3+4 : as in “Model-based design” (designing a model of a concurrent system) 12 : as in “Model-checking” (checking implementation against declarative (logic)

specification)

Main Entry: 1mod·el Pronunciation: 'mä-d&lFunction: nounEtymology: Middle French modelle, from Old Italian modello, from (assumed) Vulgar Latin modellus, from Latin modulus small measure, from modus1 obsolete : a set of plans for a building2 dialect British : COPY, IMAGE3 : structural design <a home on the model of an old farmhouse>4 : a usually miniature representation of something; also : a pattern of something to be made5 : an example for imitation or emulation6 : a person or thing that serves as a pattern for an artist; especially : one who poses for an artist7 : ARCHETYPE8 : an organism whose appearance a mimic imitates9 : one who is employed to display clothes or other merchandise : MANNEQUIN10 a : a type or design of clothing / b : a type or design of product (as a car)11 : a description or analogy used to help visualize something (as an atom) that cannot be directly observed12 : a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs13 : VERSION

Webster’s(“model”):



Model-Checking

We have seen verification: In an operational setting:

Check: (spec’ and impl’ are equiv’)

Model-checking Declarative specification ( : logic property)

Check: (impl’ satisfies property )

Declarative (vs. operational): Abstraction: “what instead of how” Stability under reimplementation Easier to read, write, and modify Logic formulae can be very concise

SPEC IMPL

IMPL |-

t,t’’: acq(t) acq(t’’) t’: t<t’<t’’ rel(t’)


CCS TOOLS

Keywords:

- Concurrency Workbench - CCS visualizer and simulator - The Bisimulation Game Game



Concurrency Workbench

[ Concurrency Workbench ]

P

testing (interactive simulation) verification (via logic formulae) dump transition graph (NFA) ...

[ http://homepages.inf.ed.ac.uk/perdita/cwb/summary.html ]

[ /users/courses/dSem/bin/cwb ]



The Concurrency Workbench

CWB:

Recommendation: try it out (before the exam)!

CWB:> input “PandQ.ccs”;

CWB:> sim(P); // run the built-in simulator

CWB:> output “P.graph”; // name output fileCWB:> graph(P); // output for CCS visualizer and simulator

CWB:> strongeq(P,Q); // strong bisimilarityCWB’s answer

CWB:> eq(P,Q); // weak bisimilarityCWB’s answer



CCS Visualizer and Simulator

[ CCS Visualizer and Simulator ]

[ http://www.brics.dk/bisim/ ]

[ /users/courses/dSem/bin/cv ]



The Bisimulation Game

It’s Amazing…

The Bisimulation Game®

Special Family Edition (w/ TV cables & remote control) Beat your sister at Process Algebra simulation…

“Special Family Edition!”

“The Bisimulation Game”

Only$31,95

The

Bisimulation

Game

[ http://www.brics.dk/bisim/ ]


SOS Implementation

Example: L



Representation of Store

type store = (variable * number) list

fun update s v n = let val s' = List.filter (fn (v', _) => v <> v') s in (v, n) :: s' end

fun lookup s v = let val pair = List.find (fn (v', _) => v = v') s fun match (SOME (_, n)) = n | match NONE = raise (Fail "Stuck!") in match pair end



Small-step semantics for Expfun smallStepExp (Variable var, store) (* Var *) = let val n = lookup store var in (Number n, store) end

| smallStepExp (Add (Number m, Number m'), store) (* Sum3 *) = let val n = m + m' in (Number n, store) end

| smallStepExp (Add (Number m, e1), store) (* Sum2 *) = let val (e1', _) = smallStepExp (e1, store) in (Add (Number m, e1'), store) end

| smallStepExp (Add (e0, e1), store) (* Sum1 *) = let val (e0', _) = smallStepExp (e0, store) in (Add (e0', e1), store) end



Pretty Printing Exp

fun prettyExp (Number n) = print (Int.toString n) | prettyExp (Variable var) = print var | prettyExp (Add (e1, e2)) = ( prettyExp e1; print " + "; prettyExp e2 ) | prettyExp (Sub (e1, e2)) = ( prettyExp e1; print " - "; prettyExp e2 ) | prettyExp (Mul (e1, e2)) = ( prettyExp e1; print " * "; prettyExp e2 )

fun prettyBExp ... =...

fun prettyCom ... = ...


COURSE EVALUATION



Course Evaluation

Your e aluation matters!: Gives you a chance to voice your opinion Helps improve next year’s course Helps improve my teaching (in general) Impacts (+/-) my personal employment

opportunities at uni May influence larger didactic strategies for whole

dept. / uni


PROGRAM EQUIVALENCE



Program Equivalence ()?

Program equivalence () ?: xFV(E2) yFV(E1)

...

How do we know they are “equivalent” ? …and what does that mean ?

C ; nil nil ; C C

if B then C else C’ if ~B then C’ else C

(C1 ; C2) ; C3 C1 ; (C2 ; C3)

repeat C until B C ; while ~B do C

x := E1 ; y := E2 y := E2 ; x := E1

nil nil ; nil



Behavior and Behavioral Equivalence

Assume deterministic language L:

Def: Behavior: Partial function :

exec(C,) =

Def: Behavioral equivalence (C C’):

’ if <C,> * ’

undef otherwise e.g. nontermination,abnormal termination

exec : Com Store Store

Store: exec(C,) = exec(C’,)i.e. the two commands produce the same resulting store, ’, (but not necessarily in the same number of steps)

if both defined



Congruence ()

Theorem: “” is a congruence [proof omitted]

i.e., we can substitute equivalent fragments in programs!

Example (Java):

C C’ => P[C] P[C’] , for all contexts P[]

class C { D void m() { S’ for (E1 ; E2 ; E3) S0

S” }}

safe transformation

who:compiler, homo-sapiens,

combination (refactoring tools), …

why:readability, optimization, simplification, …

class C { D void m() { S’ { E1 ; while (E2) { S0

E3 ; }} S” }}

class C { D void m() { S’ [ ] S’’ }}



How to Prove Behavioral Equivalence?

How do we prove: (for given C, C’)? i.e.:

For derivation sequences of any length, n

C C’

,’: (<C,> * ’) (<C’,> * ’)

Store: exec(C,) = exec(C’,) if both defined

,’: (<C,> * ’) (<C’,> * ’)

,’: (<C,> * ’) (<C’,> * ’)

,’: (<C,> n ’) (<C’,> * ’)

,’: (<C,> * ’) (<C’,> n ’)



Induction on the Length of Derivation Seq’s

Base case: P(k=1) Prove that the property, P, holds

for all derivation sequences of length 1 (one)

Inductive step: P(k) P(k+1) Assume P(k):

that the property holds for derivation sequences of length k

Prove P(k+1): that it holds for derivation sequences of length k+1

Then: n1: P(n) Property P holds for all derivation sequences (any length)



…Or

How do we prove: (for given C, C’)? i.e.:

For some intermediate configuration,

C C’

,’: (<C,> * ’) (<C’,> * ’)

Store: exec(C,) = exec(C’,) if both defined

,’: (<C,> * ’) (<C’,> * ’)

,’: (<C,> * ’) (<C’,> * ’)

: (<C,> * ) (<C’,> * )

: (<C,> * ) (<C’,> * )



Example (Proof Structure)

Example:

Prove “” (let be given w/o assumptions):

Assume [LHS]: show [RHS]:

Case analysis on possible derivations for [LHS]…

if B then C else C’ if ~B then C’ else C

<if B then C else C’, > * <if ~B then C’ else C, > *

for some

<if B then C else C’, > *

<if ~B then C’ else C, > *



Example (cont’d)

Case [B * tt]:

Then construct:

Analogous for [B * ff] Symmetric for the other direction “”

<if B then C else C’,> <C,’>C1

<B,> <tt,>B*

[IF1]

<if ~B then C’ else C,> <C,’>C1

<~B,> <ff,>B1

[IF2]

<B,> <tt,>B*

[NEG1]

proof

proof

C*

C*

’

’

proof ’

proof ’


IMPERATIVE BLOCKS



Semantics of Definitions

Semantics of Definitions:

[NIL]D

<nil, > D

<var x := A, > D ’[x=n][VAR]D

<A, > A* <n, ’>

<D0 ; D1, > D <D0’ ; D1, ’>[SEQ1]D

<D0, > D <D0’, ’>

<D0 ; D1, > D <D1, ’>[SEQ2]D

<D0, > D ’

extend store

Note: [Plotkin] does this differently (through env-store model); read it yourselves…



Semantics of Blocks

SOS for Blocks:

[BLK1]C

<begin D ; C end, > C <begin(V,0) C end, ’><D, > D ’

[BLK2]C

<begin(V,0) C end, > C <begin(V,0) C’ end, ’><C, > C <C’,’>

[BLK3]C

<begin(V,0) C end, > C (’ \ V) [0]

<C, > C ’

remember values of shadowed variables : 0 = |V

remember set of locally defined variables : V = DV(D)

purge locally defined variables and restore old shadowed values

Def: \V := {v=(v)|vDV()\V}



Dynamic vs. Static Scope Rules

Example: x := 2 ;begin var x := 7 ; nilend// here: x has the value...

[BLK3]C

<begin(V,0) C end, > C (’ \ V) [0]

<C, > C ’


“Static Scope Rules”x = 2

“Dynamic Scope Rules”x = 7

restoring old shadowed values not restoring …



Inaccessible Val’s (Garbage Collection)

Example:

[BLK3]C

<begin(V,0) C end, > C (’ \ V) [0]

<C, > C ’


// x undefinedbegin var x := 7 ; nilend// here x is ...

“No Inaccessible Values”x isn’t in the store

(garbage collection)!

“Inaccessible Values”x is in the store

(but inaccessible)!

purging locally defined vars not purging …


THE ENVIRONMENT-STORE MODEL



“The Environment-Store Model”

“The Environment-Store Model”: Introducing abstract locations:

Transitions: |- <E,> <E’,’>

x ℓ v

VAR LOC VAL

environment store

(x) ((x))x

: VAR LOC , : LOC VAL

env : doesn’t change w/ execstore: mutates with execution



Examples (Pointers)

Pointers

Static Semantics:

Dynamic Semantics:

ptr p = 0xCAFEBABE; // (p) LocZ 0xff is a location const

int x = *p; // *p Z (since (p) LocZ)

[DER]

|- * E :

|- E : LOC

[DER2]

|- <* E,> <* E’,’> |- <* ℓ,> <n,>n = (ℓ)

[DER1]

|- <E,> <E’,’>

#define ptr (int*)(for the C-hackers: :)

"DER" for (pointer) dereference



Examples (cont’d)

Aliasing (similarly with call-by-reference):

Explicit allocation:

Explicit deallocation:

{ ptr p = allocate(1); // (p) = ℓfresh ℓfresh LocZ

*p = 42; // side-effecting: ’ = [ℓfresh=42]} // ℓfresh, but is an “inaccessible ref”(!)

ptr p = ...;free(p);// (p)=ℓ, but ℓ ; aka. “dangling reference”!

ptr q = p; // location aliasing: (q) = ℓ = (p)*p = 42; // side-effecting: ’ = [ℓ=42]// now *q also has the value 42: ((q)) is 42


LANGUAGE EXTENSIONS



Language Extensions

Language extensions: Simple language without variables:

E E’

Adding variables (=> environments): |- E E’ : VAR VAL

Adding assignments (=> stores): <E,> <E’,’> : VAR VAL

Adding output (=> output “tape”): <E,> <E’,’> VAL*



SOS Extensions (cont’d)

…more extensions: Adding stack operations (=> value stack)

<E,s> <E’,s’> s VAL*

Runtime-errors (=> error values): E errorK = Exp {errorK}

Exceptions (=> exception values): E exceptionK = Exp {exceptionK}

Adding jumps/gotos (=> labels and label map) L |- C C’ L : LABEL

COM




…even more extensions: Adding functions (=> function environment):

F |- E E’ F : FNAME EXP

Adding statically scoped functions: F |- E E’ F : FNAME EXP

ENV

Adding procedures (=> procedure environment): P |- C C’ P : PNAME COM

Adding statically scoped procedures: P |- C C’ P : PNAME COM

ENV




…still more extensions: “First class” functions (=> function values: “closures”)

|- E E’ : VAR CLOSURE

Adding call-by-refence / pointers / arrays / … (=> abstract locations / “the environment-store model”):

|- <E,> <E’,’> : VAR LOC : LOC VAL

Adding pointer arithmetic / “address-of” / …(=> phys. locations / addresses):

|- <E,> <E’,’> : VAR ADDR : ADDR VAL

…



Expressible / Denotable / Storeable Values

Expressible Values: Values of expressions (i.e., E = EVAL)

Denotable Values: Values of identifiers/variables (i.e. : VAR DVAL)

Storeable Values: Values in the store (i.e. : LOC SVAL)

Printable Values: Values in the output (i.e. PVAL*)


OTHER SEMANTIC FORMALISMS



Operational Semantics

Operational Semantics:

Labelled Transition System: 0 = <z=x;x=y;y=z, [x=1,y=2,z=3]> 1 = <x=y;y=z, [x=1,y=2,z=1]> 2 = <y=z, [x=2,y=2,z=1]> 3 = result = [x=2,y=1,z=1]

Variations in step-sizes (small-step, big-step, …)

The meaning of a construct is specified by the computation it induces when it is executed on a machine. In particular, it is of interest how the effect of a computation is produced.

-- [Nielson & Nielson, “Semantics with Applications”, ’93]



Denotational Semantics

Denotational Semantics:

Describe everything as mathematical functions: [[ z=x;(x=y;y=z)]] =

[[ x=y;y=z ]] o [[ z=x ]] =[[ y=z ]] o [[ x=y ]] o [[ z=x ]] =s.s[y=s(z)] o s.s[x=s(y)] o s.s[z=s(x)] =s.s[x=s(y),y=s(x),z=s(x)]

Loops are expressed as fixed-points of rec’sive functors i.e., functions that takes functions as arguments

Meanings are modelled by mathematical objects that represent the effect of executing the constructs. Thus, only the effect is of interest, not how it is obtained.




Axiomatic Semantics

Axiomatic Semantics:

Partial correctness; Command C is partially correct wrt. a pre and a post-

condition if whenever the initial state fulfils the pre-condition and the program terminates, then the final state fulfils the post-condition.

{x=a,y=b} z=x;x=y;y=z {x=b,y=a}

Specific properties of the effect of executing the constructs are expressed as assertions. Thus, there may be aspects of the executions that are ignored.


{ pre } C { post }


</ SEMANTICS >



Program Relationship (Example c)

Program worldModel world

ConcreteAbstract

~

P

P’

M

M’

1. P ~ P’ ?2. abstract

3. M ~ M’ ?

4. relate

5. M ~ M’ !6. concretize7. P ~ P’ !


Next week: Revision Period ; then Exam

Good Luck!

Any Questions?

c laus b rabrand s emantics (q1,’06) o ct 12, 2006 c laus b rabrand © 2005-2006, university of...

Documents

processes s

bisimilar s

largest bisimulation

c laus b rabrand s emantics

s trong b isimulation

t r note

t iff strong bisimulation

bisimulation game slide