Semantics of Imperative Objects

Transcription

1 Semantics of Imperative Objects Catalin Hritcu Supervisor: Jan Schwinghammer Responsible: Prof. Gert Smolka Programming Systems Lab Saarland University, Saarbrücken November

2 Overview Imperative Object Calculus Operational Semantics Syntactic Types Axiomatic Semantics Denotational Semantics Step-indexed Semantics Possible Extensions 2 Semantics is a way to assign a meaning to programs written in a programming language, in our case the imperative object calculus. The goal of my thesis is develop a step-indexed semantics for the imperative object calculus, which we plan to extend it in several directions. However, before that I m going to present the imperative object calculus with it s operational, axiomatic and denotational semantics.

3 Object Calculi Object-oriented programming languages Idealized models Rigorously defined semantics Simple - only one primitive: objects Expressive can encode: classes and inheritance but also functions (the lambda calculus) The object calculi are object-oriented programming languages. They are abstractions (idealised morels) which capture the essence of object-oriented programming languages. 3 They have rigourously defined formal semantics And they are simple since only objects are considered as primitives. At the same time, they are expressive enough to encode all common features of practical object-oriented programming languages like classes and inheritance. But they can also easily encode functions - the lambda calculus can be easily encoded.

4 Object Calculi Object-based (not class-based) In practice: JavaScript, Self, etc. Strongly-typed A Theory of Objects [Abadi & Cardelli 96] We study the imperative object calculus [Abadi & Leino, 04] Since the object calculi only have objects as primitives they are called object-based in contrast to the much more widely used class-based programming languages like Java or C#. 4 And even though object-based programming languages are not very popular in practice, there is one important exception: JavaScript is object-based. And in the upcoming 2.0 version it will have classes, namespaces and optional types. The object calculi are of course all typed. and they are described in the book by Abadi and Cardelli: A Theory of Objects In this talk I will only discuss a variant of the imperative object calculus, as presented by Abadi and Leino in their paper from 2004.

5 Imperative Object Calculus Syntax a, b ::= x variable let x = a in b variable binding [f i = x i, m j = ς(y j )b j ] i I,j J object construction clone x object cloning x.f field selection x.f := y field update x.m method call true false booleans if x then a else b conditional 0 succ x pred x numbers More syntactic sugar used in examples Here is the syntax of our calculus. 5 Since the language is imperative, computations are described in terms of a store and statements can read and from the store and write to the store. Variables are identifiers and they are not mutable. Programs are flat -> this makes evaluation order explicit - given by the let constructs. The self reference can be used used for direct recursion - same role as this in Java, C++, C# Objects are references and the semantics allows for aliasing. Methods don t have arguments, but we can use the fields (in a similar way to the encoding of lambda calc.) We have update for fields but not for methods [-> method updates can be easily be simulated] Other than the objects we also have booleans and numbers which we will use in the examples. In the examples we will also use a lot of syntactic sugar.

6 Example Programs Factorial [fac = ς(y)λn.if n = 0 then 1 else n y.fac(n 1)] Euclid s gcd algorithm [gcd = ς(y)λx.λz.if x < z then y.gcd x (z x) else if z < x then y.gcd (x z) z else x] 6

7 Operational Semantics Abstract machine Small-step: evaluation = Reduction Relation: Config Config Configurations: σ, a Config = Store LProg (Red-Let1) (Red-Let2) σ, a σ, a σ, let x = a in b σ, let x = a in b σ, let x = v in b σ, b[x v] (Red-If-True) σ, if true then a else b σ, a (Red-If-False) σ, if false then a else b σ, b In order to define an operational semantics one constructs a simple abstract machine. The meaning of a program is the result obtained by evaluating it using this machine. 7 Since for our imperative object calculus we use a small-step operational semantics, evaluation is defined as the reflexive transitive closure of a reduction relation, which (the reduction relation) defines transitions or steps between two configurations of the abstract machine. The configurations of our abstract machine are just pairs formed by a store and a partially evaluated program. Reduction relation is inductively defined by rules, one for each construct in our language.

8 Operational Semantics (Rel-Obj) (Red-Clone) (Rel-Sel) (Red-Inv) (Red-Upd) l dom σ o = [f i = v i, m j = ς(y j )b j ] i I,j J σ, [f i = v i, m j = ς(y j )b j ] i I,j J σ[l o], l l dom σ σ l = o σ, clone l σ[l o], l σ l f = v σ, l.f σ, v σ l m = ς(y)b σ, l.m σ, b[y l] σ l f σ = σ[l (σ l)[f v]] σ, l.f := v σ, l 8

9 Example Reduction, let y = [m = ς(x)x.m] in y.m l = [m = ς(x)x.m], let y = l in y.m l = [m = ς(x)x.m], l.m l = [m = ς(x)x.m], l.m... Nonterminating evaluation This program defines an object with a method that directly calls itself and then calls that method. This or course diverges. 9

10 Types of Objects Simple types: T ::= Bool Nat [f i : T i, m j : S j ] i I,j J Typing relation: (Γ a : T ) : (Var fin Ty) Prog Ty Types are purely syntactical Subtyping (fields invariant, methods covariant) Bool Bool Nat Nat j J : S j R j I I J J [f i : T i, m j : S j ] i I,j J [f i : T i, m j : R j ] i I,j J Simple types: booleans, naturals and object types. 10 The typing relation is just a tri-place relation, inductively defined by rules. So types are purely syntactical objects. A subtyping relation is defined on object types. Other than the subtyping in width (a subtype can have additional fields and methods compared to the supertype), we also have covariance on method types (an object having a method returning a subtype has a subtype of the same object having a method returning a supertype... complicated). But in order to have soundness the fields need to be invariant because they are mutable references.

11 Typing Rules (T-Sub) T T Γ a : T Γ a : T (T-True) Γ true : Bool (T-Var) Γ x = T Γ x : T (T-False) Γ false : Bool (T-If) Γ x : Bool Γ a : T Γ b : T Γ if x then a else b : T (T-Let) Γ a : S Γ, x : S b : T Γ let x = a in b : T 11

12 Typing Rules (T-Obj) Γ x i : T i Γ, y j : T b j : S j Γ [f i = x i, m j = ς(y j )b j ] i I,j J : T where T = [f i : T i, m j : S j ] i I,j J (T-Clone) Γ x : T T = [f i : T i, m j : S j ] i I,j J Γ clone x : T (T-Upd) Γ x : [f : T ] Γ x.f := y : [] Γ y : T (T-Sel) Γ x : [f : T ] Γ x.f : T (T-Inv) Γ x : [m : T ] Γ x.m : T The types of objects can be extended to specifications of program correctness - which brings us to the next concept we want to present: program logics. 12

13 Program logic Deduction system for program correctness E.g. Hoare logic [Floyd, 67] [Hoare, 69] {p b}s 1 {q} {p b}s 2 {q} {p}if b then S 1 else S 2 {q} Widely used in program verification (E.g. Verisoft) A program logic is a deduction system for program correctness. The best example for a program logic is Hoare logic. 13 Explain rule: read from bottom up, triples: precondition, statement, postcondition Program logics are still widely used in program verification, for example the Verisoft project uses Hoare logic.

14 The Logic of Objects [Abadi & Leino, 97] [Abadi & Leino, 04] Specifications generalize types A refinement of the type system (undecidable) Attempt to mechanize [Hofmann & Tang, 02] Γ a : T E a : A :: ϕ φ is a first-order logic formula (pre + post) Sub-specification generalizes subtyping Subsumption corresponds to weakening The Logic of Objects defined by Abadi and Leino is a refinement of the type system we have seen. But since we are now talking about program correctness in the logic type checking no longer decidable. There were attempts to partially mechanize this logic, for example [Hofmann & Tang, 02] build a verification condition generator for this logic. 14 Specifications generalize types. what was added to the usual typing judgement is a first-order logic formula talking about the store, both before and after the execution of the program. The authors call this formula phi, containing both precondition and postcondition, a transition relation. Sub-specification generalizes subtyping and subsumption corresponds to weakening in Hoare logic.

15 The Logic of Objects (S-Obj) E x i : A i :: Res(x i ) E, y j : A b j : B j :: ϕ j E [f i = x i, m j = ς(y j )b j ] i I,j J : A :: ϕ where A = [f i : A i, m j : ς(y i )B j :: ϕ j ] i I,j J and ϕ = alloc(r) ` alloc(r) i I σ(r, f i) = x i ( z. z r ( alloc(z) ` alloc(z) w. `σ(z, w) σ(z, w))) and Res(e) r = e ( x. w. alloc(x) ` alloc(x) Specifications not tight (as in separation logic) `σ(x, w) = σ(x, w)) Soundness hard to prove [Reus & Schwinghammer, 06] Explain rule for object creation. 15 The assertions about the store don t have tight semantics (as in separation logic), this leads to many useless proof steps, proving that things don t change. In the paper from 2004, Abadi and Leino prove agreement between the operational semantics and their program logic: if you can prove a program returns a certain value, then the program either diverges or it reduces to that value. The more usual soundness (everything that is derivable is valid) was much harder to prove [Schwinghammer & Reus, 06].

16 Higher-order Store Executable code can be stored General references in ML Pointers to functions in C Callbacks in Java Recursion by tying a knot in the store Example (factorial through a field) let x = [f = ς(y)λn.n] in let z = [f = x, fac = ς(y)λn.if n = 0 then 1 z.f := z else n y.f.fac(n 1)] in 16 What makes the imperative object calculus particularly interesting from a theoretical point of view, is that it combines objects with higher-order store. Higher-order store = executable code can be stored Higher-order store is present in different forms in almost all practical programming languages: -> general references in ML -> pointers to functions in C/C++ -> or callbacks in Java And it s easy to check that you have higher order store by implementing recursion through the store. Also called, tying a knot in the store.

17 Higher-order Store Imperative object calculus Operational Semantics Dynamically allocated, higher-order store Challenge: finding good semantic models Reasoning about the behavior of programs Program correctness (using a program logic) Useful for proving safety(progress&preservation) Not suitable as the basis for a program logic [Benton, 05] [Reus & Schwinghammer, 06] The imperative object calculus features: dynamically allocated, higher-order store. 17 Challenging to find good semantic models in which one can reason about the behavior of programs. Syntactic arguments, based solely on the operational semantics, are surely enough to prove properties such as type safety, but are not suitable as a basis for program logics like the one we just discussed. We believe that specifications should have a meaning independent of the particular proof system.

18 Denotational Semantics The meaning of a program is a mathematical object E.g. denotation of a lambda abstraction = function Higher-order store Solving recursive domain equations Dynamic Allocation Possible-world model = category of functors over CPOs Domain theory, category theory, order theory More abstract - reasoning about program behavior So it looks like we need to use something more abstract, like a denotational semantics. 18 In a denotational semantics the meaning of a program is a mathematical object. For example in the simply typed lambda calculus the meaning of a lambda abstraction can be a function. However, once one starts to study more realistic programming languages things are not so simple any more. Heavy machinery from domain theory, category theory and order theory is often necessary. For higher-order store the semantic domain is defined as mixed-variant recursive equation one has to solve (find fixed point?). Also, only for modeling dynamic allocation one has to move to a possible-world model, formalized as a category of functors over CPOs. The major advantage of a denotational semantics is that it abstracts away from evaluation, so it is can be used to derive much more powerful laws for reasoning about the behavior of programs.

19 Denotational Semantics For the imperative object calculus Complex [Reus & Schwinghammer, 06] Separates logical validity from derivability Specification = predicate on programs Current models are still not abstract enough Many natural equivalences do not hold Since the imperative object calculus has dynamically-allocated higher order store, its denotational semantics is of course complex - Jan just finished his Ph.D. thesis on this topic. 19 This approach is nice since separates the notion of logical validity from derivability and so it clarifies the meaning of specifications of the logic: -> A specification is a predicate over [the denotation of] programs However, even so the known models are still not abstract enough in that many natural equivalences involving state do not hold.

20 Step-indexed Semantics Foundational proof-carrying code by Appel et al. Simpler machine-checkable proofs Type soundness For (very) low-level languages Lambda calculus Recursive types [Appel & McAllester, 01] General references and polymorphism [Ahmed et al., 03] So what could be an alternative to using a denotational semantics here? Step-indexed semantics,might be one. Step-indexed semantics was was developed Appel and his collaborators in the context of foundational proof-carrying code. 20 PCC is a way of certifying that untrusted mobile code does not harm its host. Foundational PCC is a variant of PCC that aims to be more flexible and more secure than PCC, by avoiding commitment to a particular type system. Operational semantics, safety properties and type systems are directly defined in an expressive logic (e.g. HOL) and then the properties are not proved only wrt some type system, but down to the foundations of mathematics. The proponents of the step-indexed semantics argue that usual syntactic proofs of type soundness (subject reduction = progress + preservation) are hard to mechanize, since they require inductive definitions and reasoning about proofs. In general proof carrying code deals with very low-level languages, like assembler or even machine code. However, step-indexed semantics was also used for a lambda calculus with recursive types in Later this has been successfully extended to an imperative language with general references and impredicative polymorphism.

21 Step-indexed Semantics Based on a small-step operational semantics Type = set of indexed values e : k T if e behaves like an element of T for k steps Semantic approach to typing Types are predicates Type constructors functions Simpler than a cpo-based denotational semantics Used as a model for a program logic [Benton 05] Based on a small-step operational semantics, and here types are just sets of indexed values - set-theoretical model. Informally, an expression has a certain type if it behaves like an element of that type for a fixed number of steps. 21 Like in a denotational semantics types have a meaning: they can be viewed as predicates over programs, while type constructors are just functions over these predicates. However, our model is purely set theoretical, so much simpler than the models one usually has with a denotational semantics. Especially the proofs are usually by direct induction on the index. Used as a model for a program logic (for a low-level languages) [Benton 05]

22 What We Are Working On Main goal Develop a step-indexed semantics for the imperative object calculus with simple object types Proving soundness of the typing rules Extensions Enriching the type system with: Subtyping Recursive object types [Reus & Streicher, 02] [Schwinghammer, 06] Impredicative polymorphism 22 The main goal of my thesis is to develop a step-indexed semantics for the imperative object calculus with simple object types. And, once such a semantics is defined, prove the usual typing rules sound. Once this has been achieved, there are several extensions of the construction that can be investigated. The first one would be: ->Enriching the type system with features such as subtyping - should be simple recursive object types - like in Jan s thesis impredicative polymorphism - to our knowledge this was never done for the imperative object calculus before.

23 More Possible Extensions Defining a program logic extending types Construct a sound deduction system FOL assertions about the store [Benton, 05] [Abadi & Leino, 04] [Podelski & Schaefer 05] Dependent types+shallow embedding to HOL - e.g. Hoare Type Theory [Nanevski et al., 06] Local and modular reasoning Separation Logic [Reynolds, 02] ADTs - Idealized ML [Krishnaswami et al., 06] -> One further extension would be defining a program logic for the imperative object calculus, as an extension of the type system and using the step-indexed semantics we are currently developing. 23 Alternatives -> Augment the type systems with FOL assertions about the store - like we have seen in the logic of Abadi and Leino -> Extend the type systems with dependent types and use a shallow embedding to HOL (HTT) And then, well... there is the original question we had when I started reading about this thesis: Can we have local and modular reasoning for the imperative object calculus. Can we build a separation logic like the ones developed by Reynolds and O Hearn? (sep logic eases reasoning about aliasing, pointer programs) Can we reason about abstract data structures, similarly to the very recent results of Krishnaswami for Idealized ML? Those area all still open questions and will be subject to further investigation.

24 Thank you! 24

25 References [1] Martín Abadi and Luca Cardelli. A Theory of Objects. Springer, [2] Martín Abadi and K. Rustan M. Leino. A logic of object-oriented programs. In Michel Bidoit and Max Dauchet, editors, Proceedings of Theory and Practice of Software Development, volume 1214 of Lecture Notes in Computer Science, pages Springer, [3] Martín Abadi and K. Rustan M. Leino. A logic of object-oriented programs. In Nachum Dershowitz, editor, Verification: Theory and Practice. Essays Dedicated to Zohar Manna on the Occasion of his 64th Birthday, Lecture Notes in Computer Science, pages Springer, [4] Amal J. Ahmed, Andrew W. Appel, and Roberto Virga. An indexed model of impredicative polymorphism and mutable references. Princeton University, January [5] Amal J. Ahmed, Matthew Fluet, and Greg Morrisett. A step-indexed model of substructural state. In Olivier Danvy and Benjamin C. Pierce, editors, International Conference on Functional Programming (ICFP 05), pages ACM Press, [6] Andrew W. Appel and David McAllester. An indexed model of recursive types for foundational proof-carrying code. ACM Transactions on Programming Languages and Systems, 23(5): , September [7] Nick Benton. A typed, compositional logic for a stack-based abstract machine. In Zoltan Esik, editor, Asian Symposium on Programming Languages and Systems APLAS 05, volume 3780 of Lecture Notes in Computer Science, pages Springer, [8] Nick Benton. Abstracting allocation: the new new thing. In Computer Science Logic, volume 4207 of Lecture Notes in Computer Science, pages Springer, [9] Robert W. Floyd. Assigning meanings to programs. In Jacob T. Schwartz, editor, Proceedings of Mathematical Aspects of Computer Science, volume 19 of Proceedings of Symposia in Applied Mathematics, pages American Mathematical Society, April This slide won t be shown, it s here just for completeness. 25

26 References [10] C. A. R. Hoare. An Axiomatic Basis of Computer Programming. Communications of the ACM, 12: , [11] Neelakantan R. Krishnaswami, Lars Birkedal, Jonathan Aldrich, and John C. Reynolds. Idealized ML and its separation logic. Submitted, [12] Aleksandar Nanevski, Amal Ahmed, Greg Morrisett, and Lars Birkedal. Abstract predicates and mutable adts in hoare type theory. Technical Report TR-14-06, Harvard University, [13] Andreas Podelski and Ina Schaefer. Local reasoning for termination. In Workshop on Verification of Concurrent Systems with Dynamic Allocated Heap (COSMICAH05), Lisabon, July [14] Bernhard Reus and Jan Schwinghammer. Denotational semantics for a program logic of objects. Mathematical Structures in Computer Science, 16(2): , April [15] Bernhard Reus and Thomas Streicher. Semantics and logic of object calculi. In Proceedings of 17th Annual IEEE Symposium Logic in Computer Science, pages IEEE Computer Society Press, [16] John C. Reynolds. Separation logic: A logic for shared mutable data structures. In Proceedings of the 17th IEEE Symposium on Logic in Computer Science, pages IEEE Computer Society, [17] Jan Schwinghammer. Reasoning about Denotations of Recursive Objects. PhD thesis, Department of Informatics, University of Sussex, [18] Francis Tang and Martin Hofmann. Generation of verification conditions for Abadi and Leino s logic of objects. Presented at 9th International Workshop on Foundations of Object-Oriented Languages, January This slide won t be shown, it s here just for completeness. 26