Modular Bisimulation Theory for Computations and Values

Transcription

1 Modular Bisimulation Theory for Computations and Values Swansea University, UK FoSSaCS, Rome March 2013

2 Part of the project: PLanCompS EPSRC-funded, {Swansea, Royal Holloway, City}, UK Scaling up formal semantics to real-world programming languages Upcoming workshop: Scalable Language Specification (SLS13) with project partner Microsoft Research Cambridge Here we work on equivalence for operational semantics: bisimulation congruence formats

3 Bisimulation Bisimilarity provides notions of behavioural equivalence for operational semantics. Defined for transition relation s l t. If s and t are (strongly) bisimilar, they can match each step and remain bisimilar: s t and s l s implies t with t l t and s t.

4 Congruence But: Any notion of equivalence should be a congruence: For each f, s 1 t 1,..., s n t n implies f (s 1,..., s n ) f (t 1,..., t n ) one can replace a term by an equivalent term in a larger context, and the overall context remains equivalent Enables compositional reasoning Bisimilarity is not guaranteed to be a congruence!

5 Congruence formats Transition systems for operational semantics can be defined inductively by SOS rules (Plotkin) There are known formats for such rules which guarantee that bisimulation is a congruence. (GSOS, tyft/tyxt,... ) l {t i i yi : i I } f (x 1,..., x n ) l t x l x x y l x y y l y x y l x y

6 Well-suited to process algebras but not to programming languages: Programming language terms can compute values Programming language transition systems generally have auxiliary entities (stores, environments,... ) which can contain arbitrary terms

7 Well-suited to process algebras but not to programming languages: Programming language terms can compute values Programming language transition systems generally have auxiliary entities (stores, environments,... ) which can contain arbitrary terms not in congruence formats! ρ[x v] s s ρ apply(λx.s, v) apply(λx.s, v) ρ apply(λx.v 1, v 2 ) v 1

8 Contribution What about bisimulation congruence for programming languages? In this work we describe a new congruence format which: can deal adequately with computed values can deal adequately with auxiliary entities higher-order bisimulation scales up to real programming languages (supports MSOS)

9 Bisimulation for Value-computation Systems

10 Values and Computations We distinguish between value terms and computational terms. Values are, computations do (Levy) Values: Booleans, integers, function abstractions,... Computations: Expressions, commands, declarations, processes, programs,...

11 Values and computations Values can be inspected, computations have behaviour. Any observing context must be able to distinguish values e.g. true and false. But they cannot interrogate the structure of arbitrary computational terms: otherwise equivalence would reduce to syntactic identity.

12 Values and computations Values can be inspected, computations have behaviour. Any observing context must be able to distinguish values e.g. true and false. But they cannot interrogate the structure of arbitrary computational terms: otherwise equivalence would reduce to syntactic identity. Algebraic signature, values determined by a set of value constructors (true, false, thunk( ),...)

13 Value-computation Bisimulation A symmetric relation R satisfying the usual bisimulation step conditions, plus: If v(s 1,..., s n ) R v 1 with v VC, then v 1 = v(t 1,..., t n ) with s i R t i for 1 i n. Bisimilar values have the same head constructor and bisimilar arguments.

14 Value-computation Bisimulation A symmetric relation R satisfying the usual bisimulation step conditions, plus: If v(s 1,..., s n ) R v 1 with v VC, then v 1 = v(t 1,..., t n ) with s i R t i for 1 i n. Bisimilar values have the same head constructor and bisimilar arguments. Congruence format: Arguments of conclusion source, targets of premises must be patterns a term made of variables and value constructors. Generalisation of tyft format (Groote, Vaandrager) l {t i i ui : i I } f (w 1,..., w n ) l t

15 Higher-order Bisimulation for MSOS

16 Auxiliary entities For programming languages, we can place auxiliary entities (store etc) in the label indexed record of terms. Examples: env, an environment mapping identifiers to the values they are bound to ( read component) exc, which signals whether an exception has occurred, and if so which ( write component) store, a mapping from reference cells to their current value (changeable read + write component)...

17 Examples bound(x) {env=ρ, } lookup(ρ, x) y {env=update(ρ,x,v),...} y let(x, v, y) {env=ρ,...} let(x, v, y ) throw(e) {exc =exc(e), } stuck y {exc =nil,...} y catch(y, f ) {exc =nil,...} catch(y, f ) y {exc =exc(e),...} y catch(y, f ) {exc =nil,...} apply(f, e) catch(v, f ) { } v... is a variable ranging over the rest of the label provides defaults for unmentioned entities lookup is a computational constructor for maps. update, nil, exc are value constructors. NB: information flows between source, label components, target

18 Higher-order bisimulation We wish to ensure that bisimulation is a congruence. If s t is to imply throw(s) throw(t) we must allow label components to vary up to bisimulation in the step (a higher-order bisimulation).

19 Bisimulation for MSOS As before, except step condition becomes: If s R t and s l s then t, l with s R t, t l t, reads(l ) = reads(l) and writes(l) R writes(l ). Write components in the label can vary up to bisimulation

20 Bisimulation for MSOS As before, except step condition becomes: If s R t and s l s then t, l with s R t, t l t, reads(l ) = reads(l) and writes(l) R writes(l ). Write components in the label can vary up to bisimulation Congruence format: (MSOS-tyft) In the conclusion, readable components must be patterns In premises, writeable components must be patterns

21 Bisimulation for MSOS As before, except step condition becomes: If s R t and s l s then t, l with s R t, t l t, reads(l ) = reads(l) and writes(l) R writes(l ). Write components in the label can vary up to bisimulation Congruence format: (MSOS-tyft) In the conclusion, readable components must be patterns In premises, writeable components must be patterns Requires lemma: One can replace inputs (read components) for bisimilar ones to yield bisimilar outputs (write components) applicative bisimulation (Howe)

22 Conclusions

23 Expressivity MSOS-tyft format expressive enough to model Caml Light: Higher-order functions, imperative state, exceptions, mutual recursion, pattern matching,... Equivalences are valid in arbitrary program contexts

24 Expressivity MSOS-tyft format expressive enough to model Caml Light: Higher-order functions, imperative state, exceptions, mutual recursion, pattern matching,... Equivalences are valid in arbitrary program contexts [We translate Caml Light programs into reusable constructs, yielding a component-based formal semantics of the language.]

25 Further Directions Theory: Multisorted signatures Bisimulations parametrised on read components (env,... ) cf. state-based bisimilarity (Mousavi) Negative premises Practice: Larger language examples, e.g. C#, Java,...

26 Conclusions We have: defined a bisimulation congruence format dealing with computed values and auxiliary entities which supports a higher-order notion of bisimulation and Modular SOS and is expressive enough to treat a real world programming language. Thank You.

27 Appendix (some more detailed slides)

28 Value-computation signatures Definition A value-computation signature consists of a set of constructors C, each with an arity in N, and a set of value constructors VC C. We let T denote the set of terms, and V T the set of value terms whose outermost constructor is in VC. Constants like true,5,... are nullary value constructors, and hence values. cond is not a value constructor, so cond(b, C, D) is never a value. thunk is a value constructor that can wrap an arbitrary computation into a value.

29 Value-computation transition systems Fix a set of labels L. We wish to define our relation s l t with s, t T and l L to model computations. We define this via inductive rules. It is useful to introduce an additional internal relation for silent, context-insensitive steps which we write as. This relation is reflexive, transitive and a precongruence. x x x 1 y 1 x n y n f (x 1,..., y n ) f (x 1,..., y n ) x y y z x z x x 1 x 1 l y 1 x l y y 1 y

30 Value-computation Bisimulation Definition A value-computation bisimulation over a given value-computation transition system (Σ, L,, ) is a symmetric relation R T Σ T Σ such that If s R t and s l s then t with s R t and t l t. If s R t and s s then t with s R t and t t. If v(s 1,..., s n ) R t with v VC, then t v(t 1,..., t n ) with s i R t i for 1 i n. Two terms s and t are value-computation bisimilar, written s vc t, if there exists a value-computation bisimulation R with s R t.

31 Congruence Format {s i i u i : i I } f (w 1,..., w n ) t Adaptation of the tyft format [?] (Each, i { } { a : a L}.) But u i and w i generalised from variables to patterns a term made of variables and value constructors. Allows rules such as seq(skip, s) s and force(thunk(s)) s. For rules in this value-added tyft format, vc-bisimilarity is a congruence.

32 Composition and Unobservability For each label component, there are default unobservable labels for unmentioned components. print(x) {output =x,env=ρ,store=σ,store =σ,exc=nil} skip Labels may also be composed: seq(assign(y, 6), assign(x, 5)) {store=σ,store =update(σ,y,6), } seq(skip, assign(x, 5)) assign(x, 5) {store=σ 1,store =update(σ 1,x,5), } skip seq(assign(y, 6), assign(x, 5)) {store=σ,store =σ[x 6,y 5], } skip Ensures e.g. single-threaded store. Each label component is a category.

33 Bisimulation for MSOS Definition Given a value-computation transition system (Σ, L(T Σ ),, ) generated from an MSOS specification, an MSOS bisimulation is a symmetric relation R T T such that: If s R t and s L s then t, L with s R t, t L t, reads(l ) = reads(l) and writes(l) R writes(l ). If s R t and s s then t with s R t and t t. If v(s 1,..., s n ) R t with v VC, then t v(t 1,..., t n ) with s i R t i for 1 i n. Two terms s and t are MSOS bisimilar, written s msos t, if there exists an MSOS bisimulation R with s R t.

34 MSOS tyft format {s i i u i : i I } f (w 1,..., w n ) t (Each, i { } { L }.) For labels L: In the conclusion, readable components must be patterns {l = u, l = t,...} In premises i, writeable components must be patterns {l = t, l = u,...} We allow composition and unobservability in conclusion

35 Bisimilarity-preservation for unprimed entities To show congruence of bisimilarity for MSOS tyft, we need: One can replace read components (environment, initial store,... ) for bisimilar ones to yield bisimilar write components (final store, thrown exceptions,... ) and target term applicative bisimulation (Howe) If s L s and reads(l) trs then: s, tws such that s s, writes(l) tws and s L s for reads(l ) = trs and writes(l ) = tws. Theorem MSOS-bisimilarity is a congruence for the MSOS tyft format.

36 throw(x) {exc =exc(x), } stuck catch(v, x, z) v y {...} y assign(x, y) {...} assign(x, y ) deref(x) {store=σ, } lookup(σ, x) x {exc =nil,...} x catch(x, y, z) {exc =nil,...} catch(x, y, z) x {exc =exc(x 1 ),...} x catch(x, y, z) {exc =nil,...} let(y, x 1, z) assign(x, v) {store=σ,store =update(σ,x,v), } skip assign and deref are constructors for imperative store. throw and catch for exception handling. NB: provides defaults for the rest of the label (e.g. store = store, exc = nil)

37 Application and Abstraction x {...} x apply(x, y) {...} apply(x, y) y {...} y apply(v, y) {...} apply(v, y ) y {env=update(ρ,x,v),...} y apply(abs(x, y, ρ), v) {env=ρ 1,...} apply(abs(x, y, ρ), v) apply(abs(x, v 1, ρ), v 2 ) v 1 lambda(x, y) {env=ρ,...} abs(x, y, ρ)