Official Survey. Cunning Plan: Focus On Objects. The Need for a Calculus. Object Calculi Summary. Why Not Use λ-calculus for OO?

Similar documents
Programming Languages Lecture 15: Recursive Types & Subtyping

Part III. Chapter 15: Subtyping

Part III Chapter 15: Subtyping

Recursive Types and Subtyping

Recursive Types and Subtyping

Harvard School of Engineering and Applied Sciences Computer Science 152

Subtyping. Lecture 13 CS 565 3/27/06

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Programming Languages Lecture 14: Sum, Product, Recursive Types

Lecture 13: Subtyping

Tradeoffs. CSE 505: Programming Languages. Lecture 15 Subtyping. Where shall we add useful completeness? Where shall we add completeness?

CS 4110 Programming Languages & Logics. Lecture 28 Recursive Types

1 Introduction. 3 Syntax

CS-XXX: Graduate Programming Languages. Lecture 9 Simply Typed Lambda Calculus. Dan Grossman 2012

Symmetry in Type Theory

Lambda Calculi With Polymorphism

Lecture 5: The Untyped λ-calculus

Types, Expressions, and States

CS 6110 S11 Lecture 25 Typed λ-calculus 6 April 2011

Object Oriented Issues in VDM++

Last class. CS Principles of Programming Languages. Introduction. Outline

Objects, Classes, Abstractions

Lambda Calculus. Lambda Calculus

CMSC330. Objects, Functional Programming, and lambda calculus

Pure (Untyped) λ-calculus. Andrey Kruglyak, 2010

Types for References, Exceptions and Continuations. Review of Subtyping. Γ e:τ τ <:σ Γ e:σ. Annoucements. How s the midterm going?

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011

CSE 505, Fall 2008, Final Examination 11 December Please do not turn the page until everyone is ready.

Lambda Calculi With Polymorphism

CSE-321 Programming Languages 2010 Final

CS 4110 Programming Languages & Logics. Lecture 27 Recursive Types

CSE 505, Fall 2008, Final Examination 11 December Please do not turn the page until everyone is ready.

Typed Compilation Against Non-Manifest Base Classes

Typed Lambda Calculus and Exception Handling

Subtyping (cont) Lecture 15 CS 565 4/3/08

Simply-Typed Lambda Calculus

GADTs meet Subtyping

Programming Languages

Goal. CS152: Programming Languages. Lecture 15 Parametric Polymorphism. What the Library Likes. What The Client Likes. Start simpler.

Fundamentals and lambda calculus. Deian Stefan (adopted from my & Edward Yang s CSE242 slides)

A Theory of Objects. Martín Abadi & Luca Cardelli. Digital Equipment Corporation Systems Research Center. ECOOP 97 Tutorial

CS 565: Programming Languages. Spring 2008 Tu, Th: 16:30-17:45 Room LWSN 1106

This is a repository copy of The theory of classification part 3: object encodings and recursion.

CS152: Programming Languages. Lecture 23 Advanced Concepts in Object-Oriented Programming. Dan Grossman Spring 2011

(Refer Slide Time: 4:00)

CMSC 330: Organization of Programming Languages

301AA - Advanced Programming [AP-2017]

Dependant Type Systems (saying what you are) Data Abstraction (hiding what you are) Review. Dependent Types. Dependent Type Notation

Lambda Calculus. Variables and Functions. cs3723 1

What s Conformance? Conformance. Conformance and Class Invariants Question: Conformance and Overriding

Second-Order Type Systems

Featherweight Java (FJ)

Subtyping and Objects

The Untyped Lambda Calculus

COMP 1130 Lambda Calculus. based on slides by Jeff Foster, U Maryland

5. Introduction to the Lambda Calculus. Oscar Nierstrasz

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

Dependent Object Types - A foundation for Scala s type system

Subsumption. Principle of safe substitution

CSE 505: Concepts of Programming Languages

Variables. Substitution

Meeting13:Denotations

Advances in Programming Languages

Dependent Types. Announcements. Project Presentations. Recap. Dependent Types. Dependent Type Notation

Review. CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Let bindings (CBV) Adding Stuff. Booleans and Conditionals

Polymorphism. Lecture 19 CS 565 4/17/08

Polymorphic lambda calculus Princ. of Progr. Languages (and Extended ) The University of Birmingham. c Uday Reddy

Object-Oriented Languages and Object-Oriented Design. Ghezzi&Jazayeri: OO Languages 1

Operational Semantics. One-Slide Summary. Lecture Outline

CMSC 336: Type Systems for Programming Languages Lecture 5: Simply Typed Lambda Calculus Acar & Ahmed January 24, 2008

Chapter 5: Procedural abstraction. Function procedures. Function procedures. Proper procedures and function procedures

CS 360: Programming Languages Lecture 12: More Haskell

CS152: Programming Languages. Lecture 7 Lambda Calculus. Dan Grossman Spring 2011

CS-XXX: Graduate Programming Languages. Lecture 23 Types for OOP; Static Overloading and Multimethods. Dan Grossman 2012

Introduction to Lambda Calculus. Lecture 5 CS 565 1/24/08

An Imperative, First-Order Calculus with Object Extension

The Untyped Lambda Calculus

Mutable References. Chapter 1

The Typed λ Calculus and Type Inferencing in ML

Resources: The slides of this lecture were derived from [Järvi], with permission of the original author, by copy & x = 1 let x = 1 in...

Introduction to Denotational Semantics. Brutus Is An Honorable Man. Class Likes/Dislikes Survey. Dueling Semantics

Types and Programming Languages. Lecture 5. Extensions of simple types

Programming Language Features. CMSC 330: Organization of Programming Languages. Turing Completeness. Turing Machine.

CMSC 330: Organization of Programming Languages

Formal Systems and their Applications

CSE 505, Fall 2007, Final Examination 10 December Please do not turn the page until everyone is ready.

Programming Language Concepts: Lecture 19

Higher-Order Intensional Type Analysis. Stephanie Weirich Cornell University

COS 320. Compiling Techniques

The Untyped Lambda Calculus

CS-XXX: Graduate Programming Languages. Lecture 17 Recursive Types. Dan Grossman 2012

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far

Operationally Sound Update

Lecture Notes on Data Representation

Consistent Subtyping for All

Introduction to Denotational Semantics. Class Likes/Dislikes Survey. Dueling Semantics. Denotational Semantics Learning Goals. You re On Jeopardy!

Lambda Calculus. Lecture 4 CS /26/10

Introduction to Lambda Calculus. Lecture 7 CS /08/09

Incremental Rebinding

CS412/CS413. Introduction to Compilers Tim Teitelbaum. Lecture 17: Types and Type-Checking 25 Feb 08

Transcription:

Modeling and Understanding Object-Oriented Oriented Programming Official Survey Please fill out the Toolkit course survey 40142 CS 655-1 Apr-21-2006 Midnight May-04-2006 9am Why not do it this evening? #1 #2 Cunning Plan: Focus On Objects A Calculus For OO Operational Semantics Type System Expressive Power Encoding OO Features The Need for a Calculus There are many OO languages with many combinations of features We would like to study these features formally in the context of some primitive language Small, essential, flexible We want a λ-calculus or IMP for objects #3 #4 Why Not Use λ-calculus for OO? Object Calculi Summary We could define some aspects of OO languages using λ-calculus e.g., the operational semantics by means of a translation to λ-calculus But then the notion of object be secondary Functions would still be first-class citizens Some typing considerations of OO languages are hard to express in λ-calculus i.e., object-orientation is not simply syntactic sugar #5 As in λ-calculi we have operational semantics denotational semantics type systems type inference algorithms guidance for language design We will actually present a family of calculi typed and untyped first-order and higher-order type systems We start with an untyped calculus #6 1

An Untyped Object Calculus An object is a collection of methods Their order does not matter Each method has A bound variable for self (denoting the host object) A body that produces a result The only operations on objects are: Method invocations Method update Untyped Object Calculus Syntax Syntax: a, b ::= x - variables [m i = ς(x) b i ] - object constructor - ς is a variant of Greek letter σ - x is the local name for self a.m - method invocation - no arguments (just the self) a.m ς(x) b - method update - this is an expression! - the result is a copy of the object with one method changed This is called the untyped ς-calculus (Abadi & Cardelli) #7 #8 First Examples Operational Semantics An object o with two methods m 1 and m 2 m 1 returns an empty object m 2 invokes m 1 through self o = [m 1 = ς(x) [], m 2 = ς(x) x.m 1 ] A bit cell with three methods: value, set and reset value returns the value of the bit (0 initially) set sets the value to 1, reset sets the value to 0 models state without λ/imp (objects are primary) b = [ value = ς(x). 0, set = ς(x). x.value ς(y). 1, reset = ς(x). x.value ς(y). 0 ] #9 a b means that a reduces in one step to b The rules are: (let o be the object [m i = ς(x). b i ] ) o.m i [o/x] b i o.m k ς(y). b [m k = ς(y). b, m i = ς(x). b i ] (i {1,, n} - { k}) We are dealing with a calculus of objects This is a deterministic semantics (has the Church- Rosser or diamond property) #10 Expressiveness A calculus based only on methods with self How expressive is this language? Let s see. Can we encode languages with fields? Yes. Can we encode classes and subclassing? Hmm. Can we encode λ-calculus? Hmm. Encoding fields Fields are methods that do not use self Field access o.f is translated directly to method invocation o.f Field update o.f e is translated to o.f ς(x) e We will drop the ς(x) from field definitions and updates As Expressive As λ Encoding functions A function is an object with two methods arg - the actual value of the argument val - the body of the function A function call updates arg and invokes val A conversion from λ-calculus expressions x = x.arg (read the actual argument) e 1 e 2 = (e 1.arg ς(y) e 2 ).val λx. e = [arg = ς(y) y.arg, val = ς(x). e ] The initial value of the argument is undefined From now on we use λ notation in addition to ς #11 #12 2

λ-calculus into ς-calculus Encoding Classes Consider the conversion of (λx.x) 5 Let o = [ arg = ς(z) z.arg, val = ς(x) x.arg] (λx.x) 5 = (o.arg ς(y) 5).val Consider now the evaluation of this latter ς-term Let o = [ arg = ς(y) 5, val = ς(x) x.arg] (o.arg ς(y) 5).val o.val = [arg = ς(y) 5, val = ς(x) x.arg].val x.arg[o /x] = o.arg 5[o /y] = 5 #13 A class is just an object with a new method, for generating new objects A repository of code for the methods of the generated objects (so that generated objects do not carry the methods with them) Example: for generating o = [m i = ς(x) b i ] c = [new = ς(z) [m i = ς(x) z.m i x], m i = ς(self) λx. b i ] The object can also carry updateable methods Note that the m i in c are fields (don t use self) #14 Class Encoding Example A class of bit cells BitClass = [ new = ς(z). [ val = ς(x) 0, set = ς(x) z.set x, reset = ς(x) z.reset x ], set = ς(z) λx. x.val ς(y) 1, reset = ς(z) λx. x.val ς(y) 0 ] Example: BitClass.new [ val = ς(x) 0, set = ς(x) BitClass.set x, reset = ς(x) BitClass.reset x ] The new object carries with it its identity The indirection through BitClass expresses the dynamic dispatch through the BitClass method table Inheritance and Subclassing Inheritance involves re-using method bodies FlipBitClass = [ new = ς(z) (BitClass.new).flip ς(x) z.flip x, flip = ς(z) λx. x.val not (x.val) ] Example: FlipBitClass.new [ val = ς(x) 0, set = ς(x) BitClass.set x, reset = ς(x) BitClass.reset x, flip = ς(x) FlipBitClass.flip x ] We can model method overriding in a similar way #15 #16 Object Types The previous calculus was untyped Can write invocations of nonexistent methods [foo = ς(x) ].bogus We want a type system that guarantees that welltyped expressions only invoke existing methods First attempt: An object s type specifies the methods it has available: A ::= [m 1, m 2,, m n ] Not good enough: If o : [m, ] then we still don t know if o.m.m is safe We also need the type of the result of a method First-Order Object Types. Subtyping Second attempt: A ::= [m i : A i ] Specify the available methods and their result types Wherever an object is usable another with more methods should also be usable This can be expressed using (width) subtyping: #17 #18 3

Typing Rules Type System Results making an object invoking a method Theorem (Minimum types) If Γ a : A then there exists B such that for any A such that Γ a : A we have B < A If an expression has a type A then it has a minimum (most precise) type B updating a method #19 Theorem (Subject reduction) If a : A and a v then v : A Type preservation. Evaluating a well-typed expression yields a value of the same type. #20 Type Examples Consider that old BitCell object o = [ value = ς(x). 0, set = ς(x). x.value ς(y). 1, reset = ς(x). x.value ς(y). 0 ] An appropriate type for it would be BitType = [ value : int, set : BitType, reset : BitType] Note that this is a recursive type Consider part of the derivation that o : BitType (for set) Unsoundness of Covariance Object types are invariant (not co/contravariant) Example of covariance being unsafe: Let U = [] and L = [m : U] By our rules L < U Let P = [x : U, f : U] and Q = [x : L, f : U] Assume we (mistakenly) say that Q < P (hoping for covariance in the type of x) Consider the expression: q : Q = [x = [m = []], f = ς(s:q) s.x.m ] Then q : P (by subsumption with Q < P) Hence q.x [] : P This yields the object [ x = [], f = ς(s:q) s.x.m ] Hence (q.x []).f : U yet (q.x []).f fails! #21 #22 Covariance Would Be Nice Though Variance Annotations Recall the type of bit cells BitType = [ value : int, set : BitType, reset : BitType] Consider the type of flipable bit cells FlipBitType = [ value : int, set : FlipBitType, reset : FlipBitType, flip : FlipBitType] We would expect that FlipBitType < BitType Does not work because object types are invariant We need covariance + subtyping of recursive types Several ways to fix this #23 Covariance fails if the method can be updated If we never update set, reset or flip we could allow covariance We annotate each method in an object type with a variance: + means read-only. Method invocation but not update - means write-only. Method update but not invocation 0 means read-write. Allows both update and invocation We must change the typing rules to check annotations And we can relax the subtyping rules #24 4

Subtyping with Variance Annotations Invariant subtyping (Read-Write) [ m i0 : B ] < [ m i0 : B ] if B = B Covariant subtyping (Read-only) [ m i+ : B ] < [ m i+ : B ] if B < B Contravariant subtyping (Write-only) [ m i- : B ] < [ m i- : B ] if B < B Classes, Types and Variance Recall the type of bit cells BitType = [ value 0 : int, set + : BitType, reset + : BitType] Consider the type of flipable bit cells FlipBitType = [ value 0 : int, set + : FlipBitType, reset + : FlipBitType, flip + : FlipBitType] Now we have FlipBitType < BitType Recall the subtyping rule for recursive types In some languages these annotations are implicit e.g., only fields can be updated #25 #26 Classes and Types Let A = [m i : B i ] be an object type Let Class(A) be the type of classes for objects of type A Class(A) = [new : A, m i : A B i ] A class has a generator and the body for the methods Types are distinct from classes A class is a stamp for creating objects Many classes can create objects of the same type Some languages take the view that two objects have the same type only if they are created from the same class With this restriction, types are classes In Java both classes and interfaces act as types #27 Higher-Order Object Types We can define bounded polymorphism Exmaple: we want to add a method to BitType that can copy the bit value of self to another object lendval = ς(z) λx:t<bittype. x.val z.val Can be applied to a BitType or a subtype lendval : t < BitType. t t Returns something of the same type as the input Can infer that z.lendval y : FlipBitType if y : FlipBitType We can add bounded existential types Ex: abstract type with interface make and and Bits = t < BitType. {make : nat t, and : t t t} We only know the representation type t < BitType #28 Conclusions Object calculi are both simple and expressive Simple: just method update and method invocation Functions vs. objects Functions can be translated into objects Objects can also be translated into functions But we need sophisticated type systems A complicated translation Classes vs. objects Class-based features can be encoded with objects: subclassing, inheritance, overriding Homework Good luck with your project presentations! Have a lovely summer. #29 #30 5