Object-Oriented Design Lecture 7 CSU 370 Fall 2008 (Pucella) Friday, Oct 3, 2008

Similar documents
CMSC 330: Organization of Programming Languages

Object-Oriented Design Lecture 14 CSU 370 Fall 2007 (Pucella) Friday, Nov 2, 2007

Equality for Abstract Data Types

Code Reuse: Inheritance

The Java Type System (continued)

CS558 Programming Languages

8 Understanding Subtyping

CS558 Programming Languages

Outline. Introduction Concepts and terminology The case for static typing. Implementing a static type system Basic typing relations Adding context

Subclassing for ADTs Implementation

Object-Oriented Design Lecture 3 CSU 370 Fall 2007 (Pucella) Friday, Sep 14, 2007

Operational Semantics. One-Slide Summary. Lecture Outline

Intro. Scheme Basics. scm> 5 5. scm>

Type Inference Systems. Type Judgments. Deriving a Type Judgment. Deriving a Judgment. Hypothetical Type Judgments CS412/CS413

The Substitution Model

Lecture 7: Primitive Recursion is Turing Computable. Michael Beeson

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

Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore

Computer Science Department Carlos III University of Madrid Leganés (Spain) David Griol Barres

Formal Semantics. Prof. Clarkson Fall Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack

Project 6 Due 11:59:59pm Thu, Dec 10, 2015

Announcements. Working on requirements this week Work on design, implementation. Types. Lecture 17 CS 169. Outline. Java Types

Lecture 10 Parsing 10.1

CS103 Handout 29 Winter 2018 February 9, 2018 Inductive Proofwriting Checklist

APCS Semester #1 Final Exam Practice Problems

We have written lots of code so far It has all been inside of the main() method What about a big program? The main() method is going to get really

Following is the general form of a typical decision making structure found in most of the programming languages:

Introduction to Programming Using Java (98-388)

CMSC 330: Organization of Programming Languages. OCaml Expressions and Functions

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.

Text Input and Conditionals

Algebraic Specifications

CS111: PROGRAMMING LANGUAGE II

16 Multiple Inheritance and Extending ADTs

School of Computer Science CPS109 Course Notes 5 Alexander Ferworn Updated Fall 15

CSE 12 Abstract Syntax Trees

CS 251 Intermediate Programming Methods and Classes

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

Induction and Semantics in Dafny

MIDTERM EXAMINATION - CS130 - Spring 2005

Please write your name and username here legibly: C212/A592 6W2 Summer 2017 Early Evaluation Exam: Fundamental Programming Structures in Java

Lecture 3: Recursion; Structural Induction

(Provisional) Lecture 22: Rackette Overview, Binary Tree Analysis 10:00 AM, Oct 27, 2017

CS152 Programming Language Paradigms Prof. Tom Austin, Fall Syntax & Semantics, and Language Design Criteria

Dialects of ML. CMSC 330: Organization of Programming Languages. Dialects of ML (cont.) Features of ML. Functional Languages. Features of ML (cont.

1007 Imperative Programming Part II

The Environment Model

CSCI-GA Scripting Languages

UNIT I Programming Language Syntax and semantics. Kainjan Sanghavi

Operational Semantics of Cool

Lecture 15 CIS 341: COMPILERS

CS-211 Fall 2017 Test 1 Version A Oct. 2, Name:

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

CPS 506 Comparative Programming Languages. Syntax Specification

Semantic Analysis. Lecture 9. February 7, 2018

CSE 113 A. Announcements - Lab

Decision Making in C

Static Semantics. Lecture 15. (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1

Programming Lecture 3

Object-Oriented Design Lecture 5 CSU 370 Fall 2008 (Pucella) Friday, Sep 26, 2008

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013

Operational Semantics of Cool

3.Constructors and Destructors. Develop cpp program to implement constructor and destructor.

CS1622. Semantic Analysis. The Compiler So Far. Lecture 15 Semantic Analysis. How to build symbol tables How to use them to find

COS 126 Exam Review. Exams overview Example programming exam Example written exam questions (part 1)

Lecture Programming in C++ PART 1. By Assistant Professor Dr. Ali Kattan

Operational Semantics

Fundamentals. Fundamentals. Fundamentals. We build up instructions from three types of materials

CSE P 501 Exam 8/5/04

Compilers and computer architecture: Semantic analysis

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

CS313D: ADVANCED PROGRAMMING LANGUAGE

Ch. 12: Operator Overloading

Principles of Programming Languages

Scope of this lecture. Repetition For loops While loops

Lecture #23: Conversion and Type Inference

CSCI 1260: Compilers and Program Analysis Steven Reiss Fall Lecture 4: Syntax Analysis I

Fall Lecture 3 September 4. Stephen Brookes

Conversion vs. Subtyping. Lecture #23: Conversion and Type Inference. Integer Conversions. Conversions: Implicit vs. Explicit. Object x = "Hello";

Review Chapter 6 in Bravaco. Short Answers 1. This type of method does not return a value. a. null b. void c. empty d. anonymous

Object Class. EX: LightSwitch Class. Basic Class Concepts: Parts. CS257 Computer Science II Kevin Sahr, PhD. Lecture 5: Writing Object Classes

CS 242. Fundamentals. Reading: See last slide

Lecture Notes on Intermediate Representation

Semantic Analysis and Type Checking

1 Inheritance (8 minutes, 9 points)

Binghamton University. CS-211 Fall Syntax. What the Compiler needs to understand your program

CS 251 Intermediate Programming Methods and More

Relation Overriding. Syntax and Semantics. Simple Semantic Domains. Operational Semantics

CS131 Typed Lambda Calculus Worksheet Due Thursday, April 19th

Functions and Methods. Questions:

Lecture Compiler Middle-End

CSE 143: Computer Programming II Summer 2017 HW4: Grammar (due Tuesday, July :30pm)

COS 126 General Computer Science Spring Written Exam 1

CISC 1600 Lecture 3.1 Introduction to Processing

Object-Oriented Design Lecture 11 CS 3500 Spring 2010 (Pucella) Tuesday, Feb 16, 2010

Instructions. Definitions. Name: CMSC 341 Fall Question Points I. /12 II. /30 III. /10 IV. /12 V. /12 VI. /12 VII.

Metaprogramming assignment 3

Lecture 2: SML Basics

Control Structures. Lecture 4 COP 3014 Fall September 18, 2017

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

Transcription:

Object-Oriented Design Lecture 7 CSU 370 Fall 2008 (Pucella) Friday, Oct 3, 2008 Type Checking Java Last lecture, we saw different kind of errors, and I indicated that some of those errors can be detected at compile-time, that is, before executing the program, and some can only be detected at run-time. The purpose of this lecture is to illustrate how Java can check the absence of type errors and method inexistence errors at compile-time, by seeing how types and especially type checking is performed. What we are after is an algorithm that runs over the source code of our program, and without actually running the code, returns either (1) a guarantee that when the code will execute it will not cause either a type error or a method-does-not-exist error, of (2) point out that there is a possible type error or method-does-not-exist error, and indicate where the error may happen. Note my use of qualification, such as possible type error, and where the error may happen. This is because the algorithm is good, but not that good. Consider the following snippets of code. if (x==0) Does this snippet of code cause an error when executed? Well, it depends on the value of variable x when it executes. Meaning that it may cause an error. And if we don t know in advance what the value of x is, we cannot say anything more. (For instance, suppose that x is input by the user.) if (x==x) This is more interesting. It never causes an error when executed, because x==x will always be true, no matter what x is. Conversely, the following code: 1

if (!(x==x)) always causes an error when executed. We want an algorithm that correctly identifies the cases above. Let s keep them in mind. Instead of defining a type-checking algorithm for all of Java, let me instead define a mini- Java that captures the essence of Java. It is a very simplified programming language, but make no mistake, it is a programming language. The type-checking algorithm works by taking a program as input. So I need to define the syntax in which we write out programs. The syntax is written using a so-called BNF grammar 1. This kind of grammar lets you define the form that different syntactic elements take, and those form can be recursive. // syntax for types T,U,V ::= void int boolean C (where C is a class name) // syntax for expressions E ::= true, false 0,1,2,,-1,-2, this x (where x is a variable or a name) E_1 + E_2 E_1 == E_2 E.f E_1.m(E_2) new C(E_1,,E_k) // syntax for statements S ::= E_1.m(E_2); return E; { Block } x = E; if E S_1 S_2 // syntax for blocks of statements 1 BNF = Backus-Naur Form 2

Block ::= T_1 x_1; ; T_k X_k; S_1 S_n A class is is of the form: class C { T_1 f_1; T_k f_k; U_1 m_1 (V_1 x_1) { Block_1 } U_n m_n (V_n x_n) { Block_n } Note that this is essentially the syntax of Java, but simplified. I will rely on your intuition of the execution model of Java to understand how programs in this babyjava execute. The only bit of subtlety is how instances of class are created. The new C(E 1,E k) operator first evaluates E 1,, E k to values v 1,, v k, and creates a new instance of class C with fields initialized to v 1,, v k. A program is a set CLS of classes. The type checker takes this set of classes, and issues a guarantee of error-freeness, or report a possible type error. Type checking a set of classes amounts to checking each class separately, but remembering the full set of classes, because we may need to refer to other classes when checking the current class. checkclasses (CLS) = for each class C in CLS, checkclass(cls,c) Type checking a class simply checks every method of the class separately, by checking the block of statements making up the body of the method. checkclass (CLS,C) = * If class C is in CLS and is of the form: class C { T_1 f_1; T_k f_k; U_1 m_1 (V_1 x_1) { Block_1 } U_n m_n (V_n x_n) { Block_n } } : checkblock(cls, C, {V_1 x_1}, Block_1, U_1) 3

checkblock(cls, C, {V_n x_n}, Block_n, U_n) Note that when checking a block, we remember that the argument to the method is assumed to have a certain type, and that the method is specified to return a specific type (which will let us check that a return in the body of the method returns the right type of value). We also carry through the current class C, remembering that class in which the method being checked lives. Checking a block of statements amounts to checking every statement in the block. Note that we record in a variable environment that type of all variables declared at the top of the block. This will be handy when we read off a value from a variable, or assign to a variable, since the environment will keep track of the type of all variables that are accessible. checkblock (CLS, C, ENV, Block, T_ret) = * If Block is of the form T_1 x_1; ; T_k x_k; S_1 S_n : let NEWENV = ENV union { T_1 x_1,, T_k x_k } checkstatement(cls, C, NEWENV, S_1, T_ret) checkstatement(cls, C, NEWENV, S_n, T_ret) Checking an individual statement is where a lot of the action takes place. Depending on the statement at hand, we check different things. checkstatement (CLS, C, ENV, S, T_ret) = * If S is of the form E_1.m(E_2) : if T_1 is not a C_1 in CLS, then report type error ("E_1 not of a known class") if C_1 has no method m in its class definition, then report type error ("Class of E_1 does not define method m") let definition of m in C_1 be U m (V x) { Block } let T_2 = typeof(cls, C, ENV, E_2) if not (T_2 = V), then report type error ("Argument does not agree m s signature") * If S is of the form return E : let T = typeof(cls, C, ENV, E) if not (T = T_ret), then report type error ("Return type of method does not agree") * If S is of the form { Block } : checkblock(cls, C, ENV, Block, T_ret) * If S is of the form x = E : 4

let T = typeof(cls, C, ENV, E) let T = lookup type of x in ENV if not (T = T ), then report type error ("Assignment types do not agree") * If S is of the form if E S_1 S_2 : let T = typeof(cls,c,env,e) if not (T = boolean), then report type error ("Conditional expects boolean condition") checkstatement(cls,c,env,s_1,t_ret) checkstatement(cls,c,env,s_2,t_ret) Finally, the following function returns the type of an expression, depending on the expression form. typeof (CLS, C, ENV, E) = * If E is of the form true or false : return boolean * If E is of the form 0,1,2,,-1,-2, : return int * If E is of the form this : return C * If E is of the form x, where x is a variable or a name: let T = lookup type of x in ENV return T * If E is of the form E_1 + E_2 : let T_2 = typeof(cls, C, ENV, E_2) if not (T_1 = T_2 = int), then report type error ("+ operation applies to integers only") return int * If E is of the form E_1 == E_2 : let T_2 = typeof(cls, C, ENV, E_2) if not (T_1 = T_2), then report type error ("== operation applies to same types") return boolean * If E is of the form E_1.f : if T_1 is not a C_1 in CLS, then report type error ("E_1 not of a known class") if C_1 has no field f in its class definition, then report type error ("Class of E_1 does not define field f") 5

let definition of f in C_1 be T f return T * If E is of the form E_1.m(E_2): if T_1 is not a C_1 in CLS, then report type error ("E_1 not of a known class") if C_1 has no method m in its class definition, then report type error ("Class of E_1 does not define method m") let definition of m in C_1 be U m (V x) { Block } let T_2 = typeof(cls, C, ENV, E_2) if not (T_2 = V), then report type error ("Argument does not agree m s signature") return U * If E is of the form new C_1(E_1,,E_n) : If C_1 is not in CLS, then report type error ("Class C_1 not known") let T_1 f_1; ; T_k f_k be the fields in C_1 if not (k = n), then report type error ("Wrong arguments number to construct C") // so, k=n let U_1 = typeof(cls, C, ENV, E_1) let U_n = typeof(cls, C, ENV, E_k) if not (U_1 = T_1) or not (U_2 = T_2) or or not (U_k = T_k) then report type error ("Argument types do not agree with fields") return C_1 It is possible to prove, although I won t do it here because it is long and requires a precise description of the execution model, that if the above algorithm does not report a type error when we invoke checkclasses(cls) for a set CLS of classes, then executing any method in any class in CLS with an argument of the right type does not cause a type error or method-not-found error at execution. The algorithm is conservative it deems that some programs may have a type error even though there is none that occur when the program is executed. For instance, it is easy to check, by looking at how checkstatement works, that the above code snippet: if (x==x) assuming it occurs in the context of a program that otherwise type checks, would fail to type 6

check: the algorithm reports a type error. That s simply because the algorithm does not take advantage of possible information it may have about whether there are guarantees that only one branch be taken. It always checks that both branches type check, even if one will never be taken when the code executes. This is a choice that the designers of the algorithm made: such choices depend on complexity of the resulting type checking algorithm, uniform behavior that is more easily predicted by the user, etc. 7