DOCSLIB.ORG

Xi Type System Specification

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

CS4120/4121/5120/5121—Spring 2019 Xi Type System Specification Cornell University Version of March 10, 2019 0 Changes • 3/10: Clarified how ARRAYDECL works. 1 Types The Xi type system uses a somewhat bigger set of types than can be expressed explicitly in the source language: t ::= int T ::= t R ::= unit s ::= var t j bool j unit j void j ret T j [] n≥2 0 t j (t1, t2,..., tn) j fn T ! T Ordinary types expressible in the language are denoted by the metavariable t, which can be int, bool, or an array type. The metavariable T denotes an expanded notion of type that represents possible types in procedures, functions, and multiple assignments. It may be an ordinary type, unit, or a tuple type. The type unit does not appear explicitly in the source language. This type is given to an element on the left-hand side of multiple assignments that uses the _ placeholder, allowing their handling be integrated directly into the type system. The unit type is also used to represent the result type of procedures. Tuple types represent the parameter types of procedures and functions that take multiple arguments, or the return types of functions that return multiple results. The metavariable R represents the outcome of evaluating a statement, which can be either unit or void. The unit type is the the type of statements that might complete normally and permit the following statement to execute. The type void is the type of statements such as return that never pass control to the following statement. The void type should not be confused with the C/Java type void, which is actually closer to unit. The set s is used to represent typing-environment entries, which can either be normal variables (bound to var t for some type t), return types (bound to ret T), functions (bound to fn T ! T0 where T0 , unit), or procedures (bound to fn T ! unit), where the “result type” unit indicates that the procedure result contains no information other than that the procedure call terminated. 2 Subtyping The subtyping relation on T is the least partial order consistent with this rule: t ≤ unit For now, however, there is no subsumption rule, so subtyping matters only where it appears explicitly. 3 Type-checking expressions To type-check expressions, we need to know what bound variables and functions are in scope; this is represented by the typing context G, which maps names x to types s. The judgment G ` e : T is the rule for the type of an expression; it states that with bindings G we can conclude that e has the type T. CS4120/4121/5120/5121 Spring 2019 1/5 Xi Type System Specification We use the metavariable symbols x or f to represent arbitrary identifiers, n to represent an integer literal constant, string to represent a string literal constant, and char to represent a character literal constant. Using these conventions, the expression typing rules are: G ` n : int G ` true : bool G ` false : bool G ` string : int[ ] G ` char : int G(x) = var t G ` e1 : int G ` e2 : int ⊕ 2 f+, -, *, *>>, /, %g G ` x : t G ` e1 ⊕ e2 : int G ` e : int G ` e1 : int G ` e2 : int 2 f==, !=, <, <=, >, >=g G ` -e : int G ` e1 e2 : bool G ` e : bool G ` e1 : bool G ` e2 : bool 2 f==, !=, &, |g G ` !e : bool G ` e1 e2 : bool G ` e : t[] G ` e1 : t[] G ` e2 : t[] 2 f==, !=g G ` length(e) : int G ` e1 e2 : bool G ` e1 : t ... G ` en : t n ≥ 0 G ` e1 : t[] G ` e2 : int G ` e1 : t[] G ` e2 : t[] G ` {e1, ... ,en} : t[] G ` e1[e2] : t G ` e1 + e2 : t[] G( f ) = fn unit ! T0 T0 , unit G( f ) = fn t ! T0 T0 , unit G ` e : t G ` f () : T0 G ` f (e) : T0 0 0 (8i21..n) G( f ) = fn (t1,..., tn) ! T T , unit G ` ei : ti n ≥ 2 0 G ` f (e1, ... ,en) : T 4 Type-checking statements To type-check statements, we need all the information used to type-check expressions, plus the types of procedures, which are included in G. In addition, we extend the domain of G a little to include a special symbol r. To check the return statement we need to know what the return type of the current function is or if it is a procedure. Let this be denoted by G(r) = ret T, where T , unit if the statement is part of a function, or T = unit if the statement is part of a procedure. Since statements include declarations, they can also produce new variable bindings, resulting in an updated typing context which we will denote as G0. To update typing contexts, we write G[x 7! var t], which is an environment exactly like G except that it maps x to var t. We use the metavariable s to denote a statement, so the main typing judgment for statements has the form G ` s : R, G0. Most of the statements are fairly straightforward and do not change G: G ` s1 : unit, G1 G1 ` s2 : unit, G2 ... Gn−1 ` sn : R, Gn (SEQ) (EMPTY) G ` {s1 s2 ... sn} : R, G G ` {} : unit, G 0 0 00 G ` e : bool G ` s : R, G G ` e : bool G ` s1 : R1, G G ` s2 : R2, G (IF) (IFELSE) G ` if (e) s : unit, G G ` if (e) s1 else s2 : lub(R1, R2), G CS4120/4121/5120/5121 Spring 2019 2/5 Xi Type System Specification G ` e : bool G ` s : R, G0 (WHILE) G ` while (e) s : unit, G G( f ) = fn unit ! unit G( f ) = fn t ! unit G ` e : t (PRCALLUNIT) (PRCALL) G ` f () : unit, G G ` f (e) : unit, G (8i21..n) G( f ) = fn (t1,..., tn) ! unit G ` ei : ti n ≥ 2 (PRCALLMULTI) G ` f (e1, ... ,en) : unit, G G(r) = ret unit G(r) = ret t G ` e : t (RETURN) (RETVAL) G ` return : void, G G ` return e : void, G (8i21..n) G(r) = ret (t1, t2,..., tn) G ` ei : ti n ≥ 2 (RETMULTI) G ` return e1, e2, ... , en : void, G The function lub is defined as follows: lub(R, R) = R lub(unit, R) = lub(R, unit) = unit Therefore, the type of an if is void only if all branches have that type. Assignments require checking the left-hand side to make sure it is assignable: G(x) = var t G ` e : t G ` e1 : t[] G ` e2 : int G ` e3 : t (ASSIGN) (ARRASSIGN) G ` x = e : unit, G G ` e1[e2] = e3 : unit, G Declarations are the source of new bindings. Three kinds of declarations can appear in the source language: variable declarations, multiple assignments, and function/procedure declarations. We are only concerned with the first two kinds within a function body. To handle multiple assignments, we define a declaration d that can appear within a multiple assignment: d ::= x:t j _ and define functions typeof (d) and varsof (d) as follows: typeof (x:t) = t typeof (_) = unit varsof (x:t) = fxg varsof (_) = Æ Using these notations, we have the following rules: x < dom(G) x < dom(G) G ` e : t (VARDECL) (VARINIT) G ` x:t : unit, G[x 7! var t] G ` x:t = e : unit, G[x 7! var t] (8i21..n) G ` e : t x < dom(G) G ` ei : int n ≥ 1 m ≥ 0 (EXPRSTMT) (ARRAYDECL) G ` _ = e : unit, G G ` x:t[e1] ... [en] [] ... [] : unit, G[x 7! var t [] ... []] | {z } | {z } m n+m (8i21..n) G ` e : (t1,..., tn) ti ≤ typeof (di) (8i21..n) (8i,j21..n.j,i) dom(G) \ varsof (di) = Æ varsof (di) \ varsof (dj) = Æ (MULTIASSIGN) (8i21..n8x .varsof (d )=fx g) G ` d1, ... ,dn = e : unit, G[xi 7! var typeof (di) i i i ] The final premise in rule MULTIASSIGN prevents shadowing by ensuring that dom(G) and all of the varsof (di)’s are disjoint from each other. With respect to (ARRAYDECL), note that the case of declaring an array with no dimension sizes specified (n = 0) is already covered by (VARDECL). CS4120/4121/5120/5121 Spring 2019 3/5 Xi Type System Specification 5 Checking top-level declarations At the top level of the program, we need to figure out the types of procedures and functions, and make sure their bodies are well-typed. Since mutual recursion is supported, this needs to be done in two passes. First, we use the judgment G ` fd : G0 to state that the function or procedure declaration fd extends top-level bindings G to G0: f < dom(G) f < dom(G) G ` f () s : G[ f 7! fn unit ! unit] G ` f (x:t) s : G[ f 7! fn t ! unit] 0 f < dom(G) G = G[ f 7! fn (t1,..., tn) ! unit] n ≥ 2 0 G ` f (x1:t1, ... ,xn:tn) s : G f < dom(G) f < dom(G) G ` f ():t0 s : G[ f 7! fn unit ! t0] G ` f (x:t):t0 s : G[ f 7! fn t ! t0] 0 0 f < dom(G) G = G[ f 7! fn (t1,..., tn) ! t ] n ≥ 2 0 0 G ` f (x1:t1, ... ,xn:tn):t s : G 0 0 0 f < dom(G) G = G[ f 7! fn unit ! (t1,..., tm)] m ≥ 2 0 0 0 G ` f ():t1, ... ,tm s : G 0 0 0 f < dom(G) G = G[ f 7! fn t ! (t1,..., tm)] m ≥ 2 0 0 0 G ` f (x:t):t1, ... ,tm s : G 0 0 0 f < dom(G) G = G[ f 7! fn (t1,..., tn) ! (t1,..., tm)] n ≥ 2 m ≥ 2 0 0 0 G ` f (x1:t1, ..
Recommended publications
  • ECSS-E-TM-40-07 Volume 2A 25 January 2011

    ECSS-E-TM-40-07 Volume 2A 25 January 2011

    ECSS-E-TM-40-07 Volume 2A 25 January 2011 Space engineering Simulation modelling platform - Volume 2: Metamodel ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands ECSS‐E‐TM‐40‐07 Volume 2A 25 January 2011 Foreword This document is one of the series of ECSS Technical Memoranda. Its Technical Memorandum status indicates that it is a non‐normative document providing useful information to the space systems developers’ community on a specific subject. It is made available to record and present non‐normative data, which are not relevant for a Standard or a Handbook. Note that these data are non‐normative even if expressed in the language normally used for requirements. Therefore, a Technical Memorandum is not considered by ECSS as suitable for direct use in Invitation To Tender (ITT) or business agreements for space systems development. Disclaimer ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error‐free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this document, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.
  • Multi-Return Function Call

    Multi-Return Function Call

    To appear in J. Functional Programming 1 Multi-return Function Call OLIN SHIVERS and DAVID FISHER College of Computing Georgia Institute of Technology (e-mail: fshivers,[email protected]) Abstract It is possible to extend the basic notion of “function call” to allow functions to have multiple re- turn points. This turns out to be a surprisingly useful mechanism. This article conducts a fairly wide-ranging tour of such a feature: a formal semantics for a minimal λ-calculus capturing the mechanism; motivating examples; monomorphic and parametrically polymorphic static type sys- tems; useful transformations; implementation concerns and experience with an implementation; and comparison to related mechanisms, such as exceptions, sum-types and explicit continuations. We conclude that multiple-return function call is not only a useful and expressive mechanism, at both the source-code and intermediate-representation levels, but also quite inexpensive to implement. Capsule Review Interesting new control-flow constructs don’t come along every day. Shivers and Fisher’s multi- return function call offers intriguing possibilities—but unlike delimited control operators or first- class continuations, it won’t make your head hurt or break the bank. It might even make you smile when you see the well-known tail call generalized to a “semi-tail call” and a “super-tail call.” What I enjoyed the most was the chance to reimagine several of my favorite little hacks using the new mechanism, but this unusually broad paper offers something for everyone: the language designer, the theorist, the implementor, and the programmer. 1 Introduction The purpose of this article is to explore in depth a particular programming-language mech- anism: the ability to specify multiple return points when calling a function.
  • Assignment 6: Subtyping and Bidirectional Typing

    Assignment 6: Subtyping and Bidirectional Typing

    Assignment 6: Subtyping and Bidirectional Typing 15-312: Foundations of Programming Languages Joshua Dunfield ([email protected]) Out: Thursday, October 24, 2002 Due: Thursday, November 7 (11:59:59 pm) 100 points total + (up to) 20 points extra credit 1 Introduction In this assignment, you will implement a bidirectional typechecker for MinML with , , +, 1, 0, , , and subtyping with base types int and float. ! ∗ 8 9 Note: In the .sml files, most changes from Assignment 4 are indicated like this: (* new asst6 code: *) ... (* end asst6 code *) 2 New in this assignment Some things have become obsolete (and have either been removed or left • in a semi-supported state). Exceptions and continuations are no longer “officially” supported. One can now (and sometimes must!) write type annotations e : τ. The • abstract syntax constructor is called Anno. The lexer supports shell-style comments in .mml source files: any line • beginning with # is ignored. There are now two valid syntaxes for functions, the old syntax fun f (x:t1):t2 is e end • and a new syntax fun f(x) is e end. Note the lack of type anno- tations. The definition of the abstract syntax constructor Fun has been changed; its arguments are now just bindings for f and x and the body. It no longer takes two types. 1 The old syntax fun f(x:t1):t2 is e end is now just syntactic sugar, transformed by the parser into fun f(x) is e end : t1 -> t2. There are floating point numbers, written as in SML. There is a new set of • arithmetic operators +., -., *., ˜.
  • Bidirectional Typing

    Bidirectional Typing

    Bidirectional Typing JANA DUNFIELD, Queen’s University, Canada NEEL KRISHNASWAMI, University of Cambridge, United Kingdom Bidirectional typing combines two modes of typing: type checking, which checks that a program satisfies a known type, and type synthesis, which determines a type from the program. Using checking enables bidirectional typing to support features for which inference is undecidable; using synthesis enables bidirectional typing to avoid the large annotation burden of explicitly typed languages. In addition, bidirectional typing improves error locality. We highlight the design principles that underlie bidirectional type systems, survey the development of bidirectional typing from the prehistoric period before Pierce and Turner’s local type inference to the present day, and provide guidance for future investigations. ACM Reference Format: Jana Dunfield and Neel Krishnaswami. 2020. Bidirectional Typing. 1, 1 (November 2020), 37 pages. https: //doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Type systems serve many purposes. They allow programming languages to reject nonsensical programs. They allow programmers to express their intent, and to use a type checker to verify that their programs are consistent with that intent. Type systems can also be used to automatically insert implicit operations, and even to guide program synthesis. Automated deduction and logic programming give us a useful lens through which to view type systems: modes [Warren 1977]. When we implement a typing judgment, say Γ ` 4 : 퐴, is each of the meta-variables (Γ, 4, 퐴) an input, or an output? If the typing context Γ, the term 4 and the type 퐴 are inputs, we are implementing type checking. If the type 퐴 is an output, we are implementing type inference.
  • Aeroscript Programming Language Reference

    Aeroscript Programming Language Reference

    AeroScript Programming Language Reference Table of Contents Table of Contents 2 Structure of a Program 5 Comments 6 Preprocessor 7 Text Replacement Macro (#define/#undef) 7 Source File Inclusion (#include) 8 Conditional Inclusion (#if/#ifdef/#ifndef) 8 Data Types and Variables 11 Fundamental Data Types 11 Fundamental Numeric Data Types 11 Fundamental String Data Type 11 Fundamental Axis Data Type 11 Fundamental Handle Data Type 12 Aggregate Data Types 12 Array Data Types 12 Structure Data Types 13 Enumerated Data Types 14 Variables 15 Variable Declaration 15 Variable Names 15 Numeric, Axis, and Handle Variable Declaration Syntax 15 String Variable Declaration Syntax 15 Syntax for Declaring Multiple Variables on the Same Line 16 Array Variable Declaration Syntax 16 Structure Variable Definition and Declaration Syntax 16 Definition Syntax 16 Declaration Syntax 17 Member Access Syntax 17 Enumeration Variable Definition and Declaration Syntax 18 Definition 18 Declaration Syntax 19 Enumerator Access Syntax 19 Variable Initialization Syntax 20 Basic Variable Initialization Syntax 20 Array Variable Initialization Syntax 21 Structure Variable Initialization Syntax 22 Enumeration Variable Initialization Syntax 22 Variable Scope 23 Controller Global Variables 23 User-Defined Variables 23 User-Defined Variable Accessibility 23 User-Defined Local Variable Declaration Location 25 Variable Data Type Conversions 26 Properties 27 Property Declaration 27 Property Names 27 Property Declaration 28 Property Usage 28 Expressions 29 Literals 29 Numeric Literals
  • (901133) Instructor: Eng

    (901133) Instructor: Eng

    home Al-Albayt University Computer Science Department C++ Programming 1 (901133) Instructor: Eng. Rami Jaradat [email protected] 1 home Subjects 1. Introduction to C++ Programming 2. Control Structures 3. Functions 4. Arrays 5. Pointers 6. Strings 2 home 1 - Introduction to C++ Programming 3 home What is computer? • Computers are programmable devices capable of performing computations and making logical decisions. • Computers can store, retrieve, and process data according to a list of instructions • Hardware is the physical part of the compute: keyboard, screen, mouse, disks, memory, and processing units • Software is a collection of computer programs, procedures and documentation that perform some tasks on a computer system 4 home Computer Logical Units • Input unit – obtains information (data) from input devices • Output unit – outputs information to output device or to control other devices. • Memory unit – Rapid access, low capacity, stores information • Secondary storage unit – cheap, long-term, high-capacity storage, stores inactive programs • Arithmetic and logic unit (ALU) – performs arithmetic calculations and logic decisions • Central processing unit (CPU): – supervises and coordinates the other sections of the computer 5 home Computer language • Machine languages: machine dependent, it consists of strings of numbers giving machine specific instructions: +1300042774 +1400593419 +1200274027 • Assembly languages: English-like abbreviations representing elementary operations, assemblers convert assembly language to machine
  • Programming with Gadts

    Programming with Gadts

    Chapter 8 Programming with GADTs ML-style variants and records make it possible to define many different data types, including many of the types we encoded in System F휔 in Chapter 2.4.1: booleans, sums, lists, trees, and so on. However, types defined this way can lead to an error-prone programming style. For example, the OCaml standard library includes functions List .hd and List . tl for accessing the head and tail of a list: val hd : ’ a l i s t → ’ a val t l : ’ a l i s t → ’ a l i s t Since the types of hd and tl do not express the requirement that the argu- ment lists be non-empty, the functions can be called with invalid arguments, leading to run-time errors: # List.hd [];; Exception: Failure ”hd”. In this chapter we introduce generalized algebraic data types (GADTs), which support richer types for data and functions, avoiding many of the errors that arise with partial functions like hd. As we shall see, GADTs offer a num- ber of benefits over simple ML-style types, including the ability to describe the shape of data more precisely, more informative applications of the propositions- as-types correspondence, and opportunities for the compiler to generate more efficient code. 8.1 Generalising algebraic data types Towards the end of Chapter 2 we considered some different approaches to defin- ing binary branching tree types. Under the following definition a tree is either empty, or consists of an element of type ’a and a pair of trees: type ’ a t r e e = Empty : ’ a t r e e | Tree : ’a tree * ’a * ’a tree → ’ a t r e e 59 60 CHAPTER 8.
  • Explicitly Implicifying Explicit Constructors

    Explicitly Implicifying Explicit Constructors

    Explicitly Implicifying explicit Constructors Document number: P1163R0 Date: 2018-08-31 Project: Programming Language C++, Library Working Group Reply-to: Nevin “☺” Liber, [email protected] or [email protected] Table of Contents Revision History ................................................................................................................ 3 P11630R0 .................................................................................................................................... 3 Introduction ....................................................................................................................... 4 Motivation and Scope ....................................................................................................... 5 Impact On the Standard ................................................................................................... 6 Policy .................................................................................................................................. 7 Design Decisions ................................................................................................................ 8 Technical Specifications ................................................................................................... 9 [template.bitset]........................................................................................................................ 10 [bitset.cons] ..............................................................................................................................
  • Scala by Example (2009)

    Scala by Example (2009)

    Scala By Example DRAFT January 13, 2009 Martin Odersky PROGRAMMING METHODS LABORATORY EPFL SWITZERLAND Contents 1 Introduction1 2 A First Example3 3 Programming with Actors and Messages7 4 Expressions and Simple Functions 11 4.1 Expressions And Simple Functions...................... 11 4.2 Parameters.................................... 12 4.3 Conditional Expressions............................ 15 4.4 Example: Square Roots by Newton’s Method................ 15 4.5 Nested Functions................................ 16 4.6 Tail Recursion.................................. 18 5 First-Class Functions 21 5.1 Anonymous Functions............................. 22 5.2 Currying..................................... 23 5.3 Example: Finding Fixed Points of Functions................ 25 5.4 Summary..................................... 28 5.5 Language Elements Seen So Far....................... 28 6 Classes and Objects 31 7 Case Classes and Pattern Matching 43 7.1 Case Classes and Case Objects........................ 46 7.2 Pattern Matching................................ 47 8 Generic Types and Methods 51 8.1 Type Parameter Bounds............................ 53 8.2 Variance Annotations.............................. 56 iv CONTENTS 8.3 Lower Bounds.................................. 58 8.4 Least Types.................................... 58 8.5 Tuples....................................... 60 8.6 Functions.................................... 61 9 Lists 63 9.1 Using Lists.................................... 63 9.2 Definition of class List I: First Order Methods..............
  • An Ontology-Based Semantic Foundation for Organizational Structure Modeling in the ARIS Method

    An Ontology-Based Semantic Foundation for Organizational Structure Modeling in the ARIS Method

    An Ontology-Based Semantic Foundation for Organizational Structure Modeling in the ARIS Method Paulo Sérgio Santos Jr., João Paulo A. Almeida, Giancarlo Guizzardi Ontology & Conceptual Modeling Research Group (NEMO) Computer Science Department, Federal University of Espírito Santo (UFES) Vitória, ES, Brazil [email protected]; [email protected]; [email protected] Abstract—This paper focuses on the issue of ontological Although present in most enterprise architecture interpretation for the ARIS organization modeling language frameworks, a semantic foundation for organizational with the following contributions: (i) providing real-world modeling elements is still lacking [1]. This is a significant semantics to the primitives of the language by using the UFO challenge from the perspective of modelers who must select foundational ontology as a semantic domain; (ii) the and manipulate modeling elements to describe an Enterprise identification of inappropriate elements of the language, using Architecture and from the perspective of stakeholders who a systematic ontology-based analysis approach; and (iii) will be exposed to models for validation and decision recommendations for improvements of the language to resolve making. In other words, a clear semantic account of the the issues identified. concepts underlying Enterprise Modeling languages is Keywords: semantics for enterprise models; organizational required for Enterprise Models to be used as a basis for the structure; ontological interpretation; ARIS; UFO (Unified management, design and evolution of an Enterprise Foundation Ontology) Architecture. In this paper we are particularly interested in the I. INTRODUCTION modeling of this architectural domain in the widely- The need to understand and manage the evolution of employed ARIS Method (ARchitecture for integrated complex organizations and its information systems has given Information Systems).
  • The Cool Reference Manual∗

    The Cool Reference Manual∗

    The Cool Reference Manual∗ Contents 1 Introduction 3 2 Getting Started 3 3 Classes 4 3.1 Features . 4 3.2 Inheritance . 5 4 Types 6 4.1 SELF TYPE ........................................... 6 4.2 Type Checking . 7 5 Attributes 8 5.1 Void................................................ 8 6 Methods 8 7 Expressions 9 7.1 Constants . 9 7.2 Identifiers . 9 7.3 Assignment . 9 7.4 Dispatch . 10 7.5 Conditionals . 10 7.6 Loops . 11 7.7 Blocks . 11 7.8 Let . 11 7.9 Case . 12 7.10 New . 12 7.11 Isvoid . 12 7.12 Arithmetic and Comparison Operations . 13 ∗Copyright c 1995-2000 by Alex Aiken. All rights reserved. 1 8 Basic Classes 13 8.1 Object . 13 8.2 IO ................................................. 13 8.3 Int................................................. 14 8.4 String . 14 8.5 Bool . 14 9 Main Class 14 10 Lexical Structure 14 10.1 Integers, Identifiers, and Special Notation . 15 10.2 Strings . 15 10.3 Comments . 15 10.4 Keywords . 15 10.5 White Space . 15 11 Cool Syntax 17 11.1 Precedence . 17 12 Type Rules 17 12.1 Type Environments . 17 12.2 Type Checking Rules . 18 13 Operational Semantics 22 13.1 Environment and the Store . 22 13.2 Syntax for Cool Objects . 24 13.3 Class definitions . 24 13.4 Operational Rules . 25 14 Acknowledgements 30 2 1 Introduction This manual describes the programming language Cool: the Classroom Object-Oriented Language. Cool is a small language that can be implemented with reasonable effort in a one semester course. Still, Cool retains many of the features of modern programming languages including objects, static typing, and automatic memory management.
  • Generic Immutability and Nullity Types for an Imperative Object-Oriented Programming Language with flexible Initialization

    Generic Immutability and Nullity Types for an Imperative Object-Oriented Programming Language with flexible Initialization

    Generic Immutability and Nullity Types for an imperative object-oriented programming language with flexible initialization James Elford June 21, 2012 Abstract We present a type system for parametric object mutability and ref- erence nullity in an imperative object oriented language. We present a simple but powerful system for generic nullity constraints, and build on previous work to provide safe initialization of objects which is not bound to constructors. The system is expressive enough to handle initialization of cyclic immutable data structures, and to enforce their cyclic nature through the type system. We provide the crucial parts of soundness ar- guments (though the full proof is not yet complete). Our arguments are novel, in that they do not require auxiliary runtime constructs (ghost state) in order to express or demonstrate our desired properties. 2 Contents 1 Introduction 4 1.1 In this document . .5 2 Background 6 2.1 Parametric Types . .6 2.1.1 Static Polymorphism through Templates . .7 2.1.2 Static Polymorphism through Generic Types . 12 2.2 Immutability . 18 2.2.1 Immutability in C++ .................... 19 2.2.2 Immutability in Java and C# ............... 21 2.2.3 An extension to Java's immutability model . 21 2.2.4 Parametric Immutability Constraints . 24 2.3 IGJ: Immutability Generic Java .................. 25 2.4 Nullity . 27 2.5 Areas of commonality . 30 3 Goals 32 4 Existing systems in more detail 34 4.1 The initialization problem . 34 4.2 What do we require from initialization? . 35 4.3 Approaches to initialization . 37 4.4 Delay Types and initialization using stack-local regions .