DOCSLIB.ORG

Obstacl: a Language with Objects, Subtyping, and Classes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Obstacl: a Language with Objects, Subtyping, and Classes OBSTACL: A LANGUAGE WITH OBJECTS, SUBTYPING, AND CLASSES A DISSERTATION SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY By Amit Jayant Patel December 2001 c Copyright 2002 by Amit Jayant Patel All Rights Reserved ii I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. John Mitchell (Principal Adviser) I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Kathleen Fisher I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. David Dill Approved for the University Committee on Graduate Studies: iii Abstract Widely used object-oriented programming languages such as C++ and Java support soft- ware engineering practices but do not have a clean theoretical foundation. On the other hand, most research languages with well-developed foundations are not designed to support software engineering practices. This thesis bridges the gap by presenting OBSTACL, an object-oriented extension of ML with a sound theoretical basis and features that lend themselves to efficient implementation. OBSTACL supports modular programming techniques with objects, classes, structural subtyping, and a modular object construction system. OBSTACL's parameterized inheritance mechanism can be used to express both single inheritance and most common uses of multiple inheritance. In addition, it can be used to implement designs that are difficult to implement with conventional single or multiple inheritance. There is a large space of possible designs for an object-oriented language. The design of OB- STACL is driven by program design and maintenance needs rather than simplicity or elegance. It explicitly supports both object and non-object forms of abstraction and does not attempt to reduce everything to an object. Although simplicity was not a goal, OBSTACL's objects and classes are simpler than those in many object-oriented languages because many of the prob- lems solved by complicated features in a purely object-oriented language are solved instead by a rich set of non-object features such as modules, first class functions, abstract data types, and parametric polymorphism (generics). In addition several fundamental questions about ab- stractions (identity, deep vs. shallow equality, copying vs. cloning, and mutation) are answered by supporting both objects and non-objects in the same language. The resulting language is straightforward to implement efficiently and relatively simple to analyze mathematically. iv Contents 1 Introduction 1 1.1 Approach . 1 1.2 Scope . 2 1.3 Language design . 4 1.4 Evaluation . 5 1.5 Theory . 6 1.6 Practice . 6 1.7 Summary . 7 2 Concepts 8 2.1 Modules . 9 2.2 Abstract Data Types . 9 2.3 Data Hiding . 10 2.4 Objects . 10 2.5 Substitutivity . 11 2.6 Prototypes . 13 2.7 Classes . 13 2.8 Inheritance . 13 2.9 Types . 15 2.10 Polymorphism . 15 3 Program Design and Maintenance 17 3.1 Modularity and Dependencies . 17 3.2 Abstractions . 19 3.2.1 Abstract Data Types . 19 3.2.2 Objects . 20 3.2.3 Union Types . 21 3.2.4 Multimethods . 22 v 3.2.5 Comparison . 24 3.3 Objects vs. Values . 25 3.4 Polymorphism . 26 3.5 Class Hierarchies . 26 3.6 Design Patterns . 27 3.6.1 Creational . 28 3.6.2 Structural . 29 3.6.3 Behavioral . 30 3.7 Summary . 30 4 Language Space 32 4.1 Using Objects . 32 4.1.1 Selection . 32 4.1.2 Updates . 33 4.1.3 Equality . 35 4.1.4 Object Types . 36 4.1.5 Super Object Type . 38 4.1.6 Access Rights . 39 4.2 Creating Objects . 41 4.2.1 Extensible Objects . 42 4.2.2 Prototypes vs. Classes . 42 4.2.3 Subtyping on Classes . 43 4.2.4 Partial Inheritance . 47 4.2.5 Run Time Inheritance . 48 4.2.6 Multiple Inheritance . 48 4.3 Initializing Objects . 52 4.3.1 Multiple Constructors . 53 4.3.2 Initialization Phases . 53 4.3.3 Order of Construction . 55 4.4 Summary . 56 5 Language Design 57 5.1 Objects . 57 5.1.1 Fields . 58 5.1.2 Methods . 58 5.1.3 Object Types . 59 5.1.4 Substitutivity . 60 5.1.5 Operations . 61 vi 5.2 Classes . 61 5.2.1 Fields . 62 5.2.2 Methods . 63 5.2.3 Inheritance . 63 5.2.4 Constructors . 64 5.2.5 Instantiators . 66 5.2.6 Class types . 68 5.3 Mixins . 70 5.3.1 Definition . 71 5.3.2 Constraints . 72 5.3.3 Application . 74 5.4 Summary . 74 6 Evaluation 75 6.1 Using and defining objects . 75 6.1.1 Equality . 75 6.1.2 Redefinitions . 77 6.2 Object Creation Patterns . 79 6.2.1 Modular Construction . 79 6.2.2 Virtual Constructor . 80 6.2.3 Object Cache . 81 6.2.4 Factory . ..
Load more

Recommended publications
  • Cyclone: a Type-Safe Dialect of C∗
    Cyclone: A Type-Safe Dialect of C∗ Dan Grossman Michael Hicks Trevor Jim Greg Morrisett If any bug has achieved celebrity status, it is the • In C, an array of structs will be laid out contigu- buffer overflow. It made front-page news as early ously in memory, which is good for cache locality. as 1987, as the enabler of the Morris worm, the first In Java, the decision of how to lay out an array worm to spread through the Internet. In recent years, of objects is made by the compiler, and probably attacks exploiting buffer overflows have become more has indirections. frequent, and more virulent. This year, for exam- ple, the Witty worm was released to the wild less • C has data types that match hardware data than 48 hours after a buffer overflow vulnerability types and operations. Java abstracts from the was publicly announced; in 45 minutes, it infected hardware (“write once, run anywhere”). the entire world-wide population of 12,000 machines running the vulnerable programs. • C has manual memory management, whereas Notably, buffer overflows are a problem only for the Java has garbage collection. Garbage collec- C and C++ languages—Java and other “safe” lan- tion is safe and convenient, but places little con- guages have built-in protection against them. More- trol over performance in the hands of the pro- over, buffer overflows appear in C programs written grammer, and indeed encourages an allocation- by expert programmers who are security concious— intensive style. programs such as OpenSSH, Kerberos, and the com- In short, C programmers can see the costs of their mercial intrusion detection programs that were the programs simply by looking at them, and they can target of Witty.
    [Show full text]
  • REFPERSYS High-Level Goals and Design Ideas*
    REFPERSYS high-level goals and design ideas* Basile STARYNKEVITCH† Abhishek CHAKRAVARTI‡ Nimesh NEEMA§ refpersys.org October 2019 - May 2021 Abstract REFPERSYS is a REFlexive and orthogonally PERsistent SYStem (as a GPLv3+ licensed free software1) running on Linux; it is a hobby2 but serious research project for many years, mostly aimed to experiment open science ideas close to Artificial General Intelligence3 dreams, and we don’t expect use- ful or interesting results before several years of hard work. audience : LINUX free software developers4 and computer scientists interested in an experimental open science approach to reflexive systems, orthogonal persistence, symbolic artificial intelligence, knowledge engines, etc.... Nota Bene: this report contains many hyperlinks to relevant sources so its PDF should rather be read on a computer screen, e.g. with evince. Since it describes a circular design (with many cycles [Hofstadter:1979:GEB]), we recommend to read it twice (skipping footnotes and references on the first read). This entire document is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. *This document has git commit fb17387fbbb7e200, was Lua-LATEX generated on 2021-May-17 18:55 MEST, see gitlab.com/bstarynk/refpersys/ and its doc/design-ideas subdirectory. Its draft is downloadable, as a PDF file, from starynkevitch.net/Basile/refpersys-design.pdf ... †See starynkevitch.net/Basile/ and contact [email protected], 92340 Bourg La Reine (near Paris), France. ‡[email protected], FL 3C, 62B PGH Shah Road, Kolkata 700032, India.
    [Show full text]
  • Spindle Documentation Release 2.0.0
    spindle Documentation Release 2.0.0 Jorge Ortiz, Jason Liszka June 08, 2016 Contents 1 Thrift 3 1.1 Data model................................................3 1.2 Interface definition language (IDL)...................................4 1.3 Serialization formats...........................................4 2 Records 5 2.1 Creating a record.............................................5 2.2 Reading/writing records.........................................6 2.3 Record interface methods........................................6 2.4 Other methods..............................................7 2.5 Mutable trait...............................................7 2.6 Raw class.................................................7 2.7 Priming..................................................7 2.8 Proxies..................................................8 2.9 Reflection.................................................8 2.10 Field descriptors.............................................8 3 Custom types 9 3.1 Enhanced types..............................................9 3.2 Bitfields..................................................9 3.3 Type-safe IDs............................................... 10 4 Enums 13 4.1 Enum value methods........................................... 13 4.2 Companion object methods....................................... 13 4.3 Matching and unknown values...................................... 14 4.4 Serializing to string............................................ 14 4.5 Examples................................................. 14 5 Working
    [Show full text]
  • Union Types for Semistructured Data
    Edinburgh Research Explorer Union Types for Semistructured Data Citation for published version: Buneman, P & Pierce, B 1999, Union Types for Semistructured Data. in Union Types for Semistructured Data: 7th International Workshop on Database Programming Languages, DBPL’99 Kinloch Rannoch, UK, September 1–3,1999 Revised Papers. Lecture Notes in Computer Science, vol. 1949, Springer-Verlag GmbH, pp. 184-207. https://doi.org/10.1007/3-540-44543-9_12 Digital Object Identifier (DOI): 10.1007/3-540-44543-9_12 Link: Link to publication record in Edinburgh Research Explorer Document Version: Peer reviewed version Published In: Union Types for Semistructured Data General rights Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer content complies with UK legislation. If you believe that the public display of this file breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim. Download date: 27. Sep. 2021 Union Typ es for Semistructured Data Peter Buneman Benjamin Pierce University of Pennsylvania Dept of Computer Information Science South rd Street Philadelphia PA USA fpeterbcpiercegcisupenn edu Technical
    [Show full text]
  • Design and Implementation of Generics for the .NET Common Language Runtime
    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
    [Show full text]
  • Gnu Smalltalk Library Reference Version 3.2.5 24 November 2017
    gnu Smalltalk Library Reference Version 3.2.5 24 November 2017 by Paolo Bonzini Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". 1 3 1 Base classes 1.1 Tree Classes documented in this manual are boldfaced. Autoload Object Behavior ClassDescription Class Metaclass BlockClosure Boolean False True CObject CAggregate CArray CPtr CString CCallable CCallbackDescriptor CFunctionDescriptor CCompound CStruct CUnion CScalar CChar CDouble CFloat CInt CLong CLongDouble CLongLong CShort CSmalltalk CUChar CByte CBoolean CUInt CULong CULongLong CUShort ContextPart 4 GNU Smalltalk Library Reference BlockContext MethodContext Continuation CType CPtrCType CArrayCType CScalarCType CStringCType Delay Directory DLD DumperProxy AlternativeObjectProxy NullProxy VersionableObjectProxy PluggableProxy SingletonProxy DynamicVariable Exception Error ArithmeticError ZeroDivide MessageNotUnderstood SystemExceptions.InvalidValue SystemExceptions.EmptyCollection SystemExceptions.InvalidArgument SystemExceptions.AlreadyDefined SystemExceptions.ArgumentOutOfRange SystemExceptions.IndexOutOfRange SystemExceptions.InvalidSize SystemExceptions.NotFound SystemExceptions.PackageNotAvailable SystemExceptions.InvalidProcessState SystemExceptions.InvalidState
    [Show full text]
  • A Proposal for a Standard Systemverilog Synthesis Subset
    A Proposal for a Standard Synthesizable Subset for SystemVerilog-2005: What the IEEE Failed to Define Stuart Sutherland Sutherland HDL, Inc., Portland, Oregon [email protected] Abstract frustrating disparity in commercial synthesis compilers. Each commercial synthesis product—HDL Compiler, SystemVerilog adds hundreds of extensions to the Encounter RTL Compiler, Precision, Blast and Synplify, to Verilog language. Some of these extensions are intended to name just a few—supports a different subset of represent hardware behavior, and are synthesizable. Other SystemVerilog. Design engineers must experiment and extensions are intended for testbench programming or determine for themselves what SystemVerilog constructs abstract system level modeling, and are not synthesizable. can safely be used for a specific design project and a The IEEE 1800-2005 SystemVerilog standard[1] defines specific mix of EDA tools. Valuable engineering time is the syntax and simulation semantics of these extensions, lost because of the lack of a standard synthesizable subset but does not define which constructs are synthesizable, or definition for SystemVerilog. the synthesis rules and semantics. This paper proposes a standard synthesis subset for SystemVerilog. The paper This paper proposes a subset of the SystemVerilog design reflects discussions with several EDA companies, in order extensions that should be considered synthesizable using to accurately define a common synthesis subset that is current RTL synthesis compiler technology. At Sutherland portable across today’s commercial synthesis compilers. HDL, we use this SystemVerilog synthesis subset in the training and consulting services we provide. We have 1. Introduction worked closely with several EDA companies to ensure that this subset is portable across a variety of synthesis SystemVerilog extensions to the Verilog HDL address two compilers.
    [Show full text]
  • Secure the Clones - Static Enforcement of Policies for Secure Object Copying Thomas Jensen, Florent Kirchner, David Pichardie
    Secure the Clones - Static Enforcement of Policies for Secure Object Copying Thomas Jensen, Florent Kirchner, David Pichardie To cite this version: Thomas Jensen, Florent Kirchner, David Pichardie. Secure the Clones - Static Enforcement of Policies for Secure Object Copying. ESOP 2011, 2011, Saarbrucken, Germany. hal-01110817 HAL Id: hal-01110817 https://hal.inria.fr/hal-01110817 Submitted on 28 Jan 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Secure the Clones * Static Enforcement of Policies for Secure Object Copying Thomas Jensen, Florent Kirchner, and David Pichardie INRIA Rennes – Bretagne Atlantique, France [email protected] Abstract. Exchanging mutable data objects with untrusted code is a delicate matter because of the risk of creating a data space that is accessible by an attacker. Consequently, secure programming guidelines for Java stress the importance of using defensive copying before accepting or handing out references to an inter- nal mutable object. However, implementation of a copy method (like clone()) is entirely left to the programmer. It may not provide a sufficiently deep copy of an object and is subject to overriding by a malicious sub-class. Currently no language-based mechanism supports secure object cloning.
    [Show full text]
  • Parametric Polymorphism Parametric Polymorphism
    Parametric Polymorphism Parametric Polymorphism • is a way to make a language more expressive, while still maintaining full static type-safety (every Haskell expression has a type, and types are all checked at compile-time; programs with type errors will not even compile) • using parametric polymorphism, a function or a data type can be written generically so that it can handle values identically without depending on their type • such functions and data types are called generic functions and generic datatypes Polymorphism in Haskell • Two kinds of polymorphism in Haskell – parametric and ad hoc (coming later!) • Both kinds involve type variables, standing for arbitrary types. • Easy to spot because they start with lower case letters • Usually we just use one letter on its own, e.g. a, b, c • When we use a polymorphic function we will usually do so at a specific type, called an instance. The process is called instantiation. Identity function Consider the identity function: id x = x Prelude> :t id id :: a -> a It does not do anything with the input other than returning it, therefore it places no constraints on the input's type. Prelude> :t id id :: a -> a Prelude> id 3 3 Prelude> id "hello" "hello" Prelude> id 'c' 'c' Polymorphic datatypes • The identity function is the simplest possible polymorphic function but not very interesting • Most useful polymorphic functions involve polymorphic types • Notation – write the name(s) of the type variable(s) used to the left of the = symbol Maybe data Maybe a = Nothing | Just a • a is the type variable • When we instantiate a to something, e.g.
    [Show full text]
  • CSE 307: Principles of Programming Languages Classes and Inheritance
    OOP Introduction Type & Subtype Inheritance Overloading and Overriding CSE 307: Principles of Programming Languages Classes and Inheritance R. Sekar 1 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Topics 1. OOP Introduction 3. Inheritance 2. Type & Subtype 4. Overloading and Overriding 2 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Section 1 OOP Introduction 3 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding OOP (Object Oriented Programming) So far the languages that we encountered treat data and computation separately. In OOP, the data and computation are combined into an “object”. 4 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP more convenient: collects related information together, rather than distributing it. Example: C++ iostream class collects all I/O related operations together into one central place. Contrast with C I/O library, which consists of many distinct functions such as getchar, printf, scanf, sscanf, etc. centralizes and regulates access to data. If there is an error that corrupts object data, we need to look for the error only within its class Contrast with C programs, where access/modification code is distributed throughout the program 5 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP (Continued) Promotes reuse. by separating interface from implementation. We can replace the implementation of an object without changing client code. Contrast with C, where the implementation of a data structure such as a linked list is integrated into the client code by permitting extension of new objects via inheritance. Inheritance allows a new class to reuse the features of an existing class.
    [Show full text]
  • INF 102 CONCEPTS of PROG. LANGS Type Systems
    INF 102 CONCEPTS OF PROG. LANGS Type Systems Instructors: James Jones Copyright © Instructors. What is a Data Type? • A type is a collection of computational entities that share some common property • Programming languages are designed to help programmers organize computational constructs and use them correctly. Many programming languages organize data and computations into collections called types. • Some examples of types are: o the type Int of integers o the type (Int→Int) of functions from integers to integers Why do we need them? • Consider “untyped” universes: • Bit string in computer memory • λ-expressions in λ calculus • Sets in set theory • “untyped” = there’s only 1 type • Types arise naturally to categorize objects according to patterns of use • E.g. all integer numbers have same set of applicable operations Use of Types • Identifying and preventing meaningless errors in the program o Compile-time checking o Run-time checking • Program Organization and documentation o Separate types for separate concepts o Indicates intended use declared identifiers • Supports Optimization o Short integers require fewer bits o Access record component by known offset Type Errors • A type error occurs when a computational entity, such as a function or a data value, is used in a manner that is inconsistent with the concept it represents • Languages represent values as sequences of bits. A "type error" occurs when a bit sequence written for one type is used as a bit sequence for another type • A simple example can be assigning a string to an integer
    [Show full text]
  • Parametric Polymorphism (Generics) 30 April 2018 Lecturer: Andrew Myers
    CS 4120/5120 Lecture 36 Parametric Polymorphism (Generics) 30 April 2018 Lecturer: Andrew Myers Parametric polymorphism, also known as generics, is a programming language feature with implications for compiler design. The word polymorphism in general means that a value or other entity that can have more than one type. We have already talked about subtype polymorphism, in which a value of one type can act like another (super)type. Subtyping places constraints on how we implemented objects. In parametric polymorphism, the ability for something to have more than one “shape” is by introducing a type parameter. A typical motivation for parametric polymorphism is to support generic collection libraries such as the Java Collection Framework. Prior to the introduction of parametric polymorphism, all that code could know about the contents of a Set or Map was that it contained Objects. This led to code that was clumsy and not type-safe. With parametric polymorphism, we can apply a parameterized type such as Map to particular types: a Map String, Point maps Strings to Points. We can also parameterize procedures (functions, methods) withh respect to types.i Using Xi-like syntax, we might write a is_member method that can look up elements in a map: contains K, V (c: Map K, V , k: K): Value { ... } Map K, V h m i h i ...h i p: Point = contains String, Point (m, "Hello") h i Although Map is sometimes called a parameterized type or a generic type , it isn’t really a type; it is a type-level function that maps a pair of types to a new type.
    [Show full text]