1. Reading, Writing and Relations Towards Extensional Semantics for Effect Analyses Andrew Kennedy Microsoft Research Cambridge (joint work with Nick Benton, Martin Hofmann & Lennart Beringer) Published in APLAS’06 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AA A A AA A A A A A A A A AAAA A A A

2. Reading and writing When is this equivalence valid? C ; if B then C 1 else C 2  if B then { C;C 1 } else { C; C 2 } Answer: when B’s reads are disjoint from C’s writes. We’re interested in effect systems that can validate equations such as this. Specifically, we want to study their semantics.

3. Effect systems Effect systems (Gifford & Lucassen) associate to every term an approximation of its effect, such as ◦ Reading from a location in the store ◦ Writing to a location in the store ◦ Throwing an exception ◦ Performing I/O ◦ Allocating an object or ref cell ◦ Diverging Effect information can be used to justify transformations e.g. in optimizing compilers.

4. Syntactic approach to effect soundness Typically, effect systems are formalized in the style of a type system Usually, only a syntactic soundness result is shown. To do this, it is often necessary to instrument the standard semantics e.g. with traces of read/write operations. This “intensional” semantics is very close to the analysis, so it’s easy to prove a soundness result. But: ◦ It doesn’t capture what types mean – it’s purely syntactic ◦ It’s a cheat: the original semantics must be modified ◦ It confuses the inference system with the semantics of information that it produces ◦ It’s very hard to use it to prove equivalences

5. Intensional vs extensional effects Code Intensional effect Extensional (observable) effect x := x + 1; x := x – 1read x, write xnone if x=3 then y := x else y := 3read x, write ywrite y if x = 2 then y := y+1 else y := y-1; if x  2 then y := y+1 else y := y-1 read x, read y, write y none

6. Extensional interpretation of effects We prefer the extensional approach: what does it actually mean to “read” or “write”? Start simple: a store consisting of just 2 integer locations. Let f be the denotation of a command i.e. f 2 Z £ Z  Z £ Z. Suppose C does not write to the first location. Extensionally: there is some g : Z £ Z  Z such that f(x,y) = (x,g(x,y)) Suppose C does not read or write the first location. Extensionally: there is some g : Z  Z such that f(x,y) = (x,g(y)) Suppose C does not read from the first location. Extensionally: there is some h : Z  B, g 1,g 2 : Z  Z such that f(x,y) = (h(y) ? x : g 1 (y), g 2 (y))

7. Relations The “does not read” effect, in particular, was a little intricate to capture. But move to a relational interpretation, and we have a much slicker characterization of reading and writing.  = diagonal relation, £ and  usual constructions on relations f : R shorthand for (f,f) 2 R C does not write to the first location: 8 R µ . f : R £  R £ . C does not read or write the first location: 8 R. f : R £  R £ . C does not read from the first location: 8 R ¶ . f : R £  R £ .

8. Framework  ` M : A «  ` M : A ¬  ` M : X Base type system Refined type system (effect annotation, subtyping) «  ` M : X ¬ “erases to” Base semantics (sets and functions) Refined semantics (partial equivalence relations over base semantics)

9. Base language Types Terms Computation type Trivial computation Sequencing of computations Read from a global integer- valued location Write to a global location Value types Call by value

10. Selected typing rules

11. Base semantics Our language is simple: no recursion, no recursive types, global store of integer locations Obvious semantics in sets and functions:

12. Refined types and subtyping Subtyping Computation type is annotated with its effect Types An effect consists of a set of read and write effects to particular locations Set inclusion on effects induces a subtyping relation

13. Selected typing rules for refined types Effects are merged in let Trivial computations have no effect Reads have “read” effect Writes have “write” effect “Latent” effects are observed on function application

14. Erasure Define a map U from refined type to underlying base type. Easy results:

15. Embedding base into refined Define map G from base types to refined types that adds the “top” annotation to computation types: Easy result:

16. Goal Use the semantics to validate equivalences at particular types. E.g. effect-independent: E.g. effect-dependent:

17. Relational semantics of effects For a simple type A, the meaning « A ¬ was a set. For a refined type X, the meaning « X ¬ is a subset of the underlying set « U(X) ¬ together with a coarser notion of equality. That is: a partial equivalence relation on « U(X) ¬ (a symmetric, transitive relation). Roughly speaking: ◦ (x,x) in « X ¬ = “semantically, x behaves as type X” ◦ (x,y) in « X ¬ = “semantically, x is equivalent to y at type X”

18. Semantics of refined types, on one slide Values of base type are related just to themselves (diagonal relation) Functions are related in the usual “logical” fashion: related arguments  related results Computations are related if they preserve all state relations that respect the effect

19. Effect-respecting relations Computations are related if they produce related results and preserve all state relations R that respect .” We say R respects reads from l if We say R respects writes to l if We say R respects  if it respects each effect e in 

20. Results Soundness of subtyping: Fundamental theorem: Meaning of top effect: Equivalences ◦ Effect-independent: congruence rules, ,  rules, commuting conversions ◦ Effect-dependent: dead computation, duplicated computation, commuting computations, pure lambda hoist ◦ Reasoning is quite intricate, involving construction of specific effect-respecting relations. See paper!

21. Effect-dependent equivalences (1)

22. Effect-dependent equivalences (2)

23. Type isomorphisms This “currying” isomorphism follows from lambda-hoist and  -  rules. Interestingly, this does not hold in our model due to the presence of “snapback” functions. Here:

24. Other applications Our general approach – of defining semantics of refined types by relations over semantics of base types – transfers to other effects. ◦ “Semantics of an Effect Analysis for Exceptions”, Benton & Buchlovsky, TLDI’07. ◦ Here, the effect is directly observable and the definition of relations is obvious. Nevertheless, they’re necessary: a predicate-based semantics is unable to validate non-trivial equivalences.

25. Future directions Recursion ◦ Relations over domains instead of sets, unproblematic in absence of dynamic allocation Higher-typed store ◦ Much more challenging Dynamic allocation and regions ◦ Our current focus: runST-style encapsulation + its semantic analogue (e.g. purity of memoize function)