DOCSLIB.ORG

An Object-Oriented Data and Query Model

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Object-Oriented Data and Query Model J Vella An object-oriented data and query model This thesis is submitted for the degree of Doctor of Philosophy 2013 An object-oriented data and query model Joseph Vella This thesis is submitted for the degree of Doctor of Philosophy, in the Department of Computer Science, University of Sheffield, March, 2013. An object-oriented data and query model Joseph Vella Abstract OODBs build effective databases with their development peaking in 2000. A reason given for its neglect is of not having a declarative and procedural language. Relevant declarative languages include ODMG OQL and Flora-2, a first order and object-oriented logic programming system based on F-Logic. Few procedural object algebras have been proposed and ours is one and none are offered together. The characteristics of the algebra proposed and implemented with Flora-2 are: it is closed; it is typed; its ranges and outputs are homogeneous sets of objects; operators work on either values or logical identifiers; a result set is asserted; and a query expression’s meta details are asserted too. The algebra has ten operators and most have algebraic properties. A framework was developed too and it has its object base loaded with methods that maintain it and our algebra. A framework’s function is to read an EERM diagram to assert the respective classes and referential constraints. The framework then sifts for non- implementable constructs in the EERM diagram and converts them into implementable ones (e.g. n-ary relationships) and translate the object base design into ODMG ODLs. This translation’s correctness and completeness is studied. The framework implements run-time type checking as Flora-2 lacks these. We develop type checking for methods that are static, with single arity, polymorphic (e.g. overloaded and bounded), and recursive structures (e.g. lists) through well-known and accepted techniques. A procedure that converts a subset of OQL into an algebraic expression is given. Once created it is manipulated to produce an optimised expression through a number of query re- writing methods: e.g. semantic, join reduction, and view materialisation. These techniques are aided by the underlying object base constructs; e.g. primary key constraint presence is used to avoid duplicate elimination of a result set. We show the importance of tight coupling in each translation step from an EERM to an algebraic expression. Also we identify invariant constructs, e.g. primary key through a select operand, which do not change from a query range to a query result set. Dedication: To our Kim Jamie and Kyle Matthew Acknowledgements: I am deeply indebted to my supervisors: Anthony JH Simons, Vitezlav Nezval, and Georg Struth. Their support and guidance is much appreciated. Also I have to say how good it feels to be part of the department at the University of Sheffield. Additionally I need to acknowledge and whole- heartedly thank the examiners for viewpoints and suggestions given. A great thank you goes to Michael Kifer for patiently guiding me, if not illuminating, to aspects of F-Logic and Flora-2. A thank you goes to the EyeDB community for their occasional help. I have to say thanks to Dropbox too; it is a life saver. My employer provided financial support and a two year studies leave; thanks very much. Special hug and kisses goes to Adriana; you are the one that I love! Object-Oriented Data and Query Models Table of Contents Title Page Abstract Acknowledgements Table of Contents ix 1 Introduction 2 1.1 Thesis Statement 4 1.2 Plan of the Thesis 4 2 Conceptual Modelling 8 2.1 ERM and EERM 8 2.1.1 Entities 9 2.1.2 Relationships 11 2.1.3 Other ERM Features 13 2.2 Enhanced ERM (EERM) 15 2.2.1 Entities and Sub-Classes 15 2.2.2. Categories / Union Records 19 2.2.3 Aggregation 20 2.3 How and How not to Use ERM 25 2.3.1. ERMs and CASE tools 26 2.4 Problems with ERM/EERM diagram 27 2.4.1 Connection Traps 28 2.4.2 Many to Many Relationships 29 2.4.3 Are Three Binary Relationships Equivalent to One Ternary Relationship? 30 2.4.4 Formalisation of the EERM 30 2.5 An Example 31 2.6 Summary 33 3 Object-Oriented Paradigm – Object Basics 36 3.1 Encapsulation 38 3.1.1 External Interfaces 38 3.1.2 Data Independence and Encapsulation 39 3.1.3 Encapsulation and Inheritance 39 3.2 Objects and Values 39 3.2.1 Basic Sets 40 3.2.2 Tuple Structured Values 41 3.2.3 Non First Normal Form Structured Values 41 3.2.4 Complex Structured Values 42 3.2.5 What gains? 43 3.3 Object Identity 45 3.3.1 Logical Aspects of Identification 48 3.3.2 Complex Value Structure and Nested Relational with Identifiers 48 3.3.3 Identifiers and Referential Integrity 50 3.3.4 Identification’s Pragmatics 50 3.4 Message Passing 52 3.4.1 The Message Passing and Method Determination Mechanisms 53 3.4.2 Message Passing and Function Calls 54 3.4.3 Method code 55 3.4.4 Concurrency and Message Passing 56 3.4.5 Message Passing in Object-Oriented Databases 56 3.5 Summary 56 Table of Contents – Page ( ix ) Object-Oriented Data and Query Models 4 Object-Oriented Paradigm – Classification and 60 Inheritance 4.1 Classes and Classification 60 4.1.1 Class and Generalisation Abstraction 62 4.1.2 Classes and Aggregation Abstraction 65 4.1.3 Prebuilt Class Hierarchy 66 4.1.4 Classes and their Composition 66 4.1.5 Class Implementations and Data Types 68 4.1.6 Classification Critique 68 4.2 Inheritance 69 4.2.1 Inheritance Mechanism 70 4.2.2 What to inherit exactly? 70 4.2.3 Incremental Development through Re-use 73 4.2.4 Single or Multiple Inheritance? 73 4.2.5 Inheritance in Conceptual Design and Implementation Design 74 4.2.6 Other Points with Inheritance 75 4.3 Data Types 75 4.3.1 Data Typing 76 4.3.2 Data Type Representation 78 4.3.3 Data Type Inference 79 4.3.4 Data Type Theory 80 4.3.5 Object-Oriented Data Typing 81 4.3.6 Advantages of Data Types 86 4.3.7 Inheritance, Sub Typing and Sub Classing are not the same thing 87 4.4 Summary 88 5 Object-Oriented Paradigm – OODB and the ODMG 92 Standard 5.1 OODB Schema and Instance 92 5.2 Path Expressions 95 5.2.1 Path Expressions in more Detail 96 5.2.2 Variables in Path Expressions 97 5.2.3 Heterogeneous set of Objects 98 5.2.4 Physical Implementation of Path Expressions 98 5.2.5 Path Expression and other Possibilities 99 5.3 The Object Data Standard: ODMG 3.0 100 5.3.1 The Generic Chapters 101 5.3.2 The OMDG Object and Data Model 102 5.3.3 Critique of ODMG’s Object Model and ODL 114 5.3.4 EyeDB 114 5.3.5 ODL & OQL Interactive Session 115 5.4 Summary 117 6 Deductive & Object-Oriented Databases 120 6.1 Deductive Databases and Datalog 120 6.1.1 Logic and Databases 121 6.1.2 Logic Programming 121 6.1.3 Deductive Databases 122 6.1.4 Datalog 124 6.1.5 Queries and Safe Answers 128 6.1.6 Datalog Evaluation: Datalog to Algebra 129 6.1.7 Extending Datalog with Negation 132 6.1.8 Extending Datalog with Functions 134 6.1.9 Datalog and Relational Algebra 135 6.2 Algebras as a target for Declarative Languages 136 6.2.1 Relational Algebra, Nested Relational Algebras & Object Algebras 136 6.3 F-logic 138 6.3.1 F-logic: the Language 139 6.3.2 F-logic's Semantics 142 6.3.3 F-logic and Predicates 143 Table of Contents – Page ( x ) Object-Oriented Data and Query Models 6.3.4 F-logic's Proof Theory 143 6.3.5 Logic Programming with F-logic 143 6.3.6 F-logic and Typing 144 6.3.7 F-logic and Inheritance 146 6.3.8 F-logic Implementation: Flora-2 149 6.3.9 Flora-2 Session 149 6.4 Summary 151 7 Integrity Constraints 154 7.1 Integrity Constraints Representation 155 7.1.1 Check Constraint 156 7.1.2 Primary Key Constraint 156 7.1.3 Not Null Constraint 156 7.1.4 Referential Constraint 157 7.1.5 Functional Dependency and Multi-Valued Dependency 157 7.1.6 Aggregate Constraint 158 7.1.7 Transitional Constraint 158 7.2 Integrity Constraints and Databases 159 7.2.1 Efficiency 159 7.2.2 Data Modelling Relationships 160 7.3 Converting Integrity Constraints into Queries of Denials 164 7.4 Other Issues 165 7.4.1 Where to “attach” ICs 165 7.4.2 Intra-IC Consistency 165 7.4.3 Redundancy of ICs 166 7.4.4 When to Apply IC Enforcement 167 7.4.5 ICs in Query Processing 167 7.4.6 Other Issues - IC in CASE Tools / Database Design 169 7.5 Summary 169 8 Framework for an Object Database Design 172 8.1 Basic Object Database Framework 172 8.1.1 Data Requirements of Framework 175 8.1.2 Logic Programming 176 8.2 Schema in F-logic 178 8.2.1 Asserting EERM Constructs into Flora-2 178 8.3 Summary 200 9 Translating an EERM into an ODL Schema 202 9.1 The Problem Definition 202 9.1.1 General Procedure 203 9.1.2 Entities, and Weak Entities 204 9.1.3 ISA Relationship 205 9.1.4 Binary Relationships 207 9.1.5 Entity Attributes 209 9.2 Sample Output 213 9.3 Completeness and Correctness 214 9.3.1 The ISA Relationship 215 9.3.2 Classes, Structures & Attributes 216 9.3.3 Binary Relationships 217 9.4 EERM to ODMG ODL Mapping 219 9.4.1 The Problem Definition 219 9.4.2 %odl_schema Output 230 9.4.3 Completeness and Correctness 230 9.4.4 Reverse Engineer an EERM Diagram from an ODL Schema 236 9.5 Summary 237 10 Type Checking in Object Database Framework 240 10.1 Problem Definition 240 10.2 Views and Flora-2 Data-Type Signatures 241 10.2.1 Views for Classifying Methods for Data-Type Checking 242 10.3 Method Signature’s Cardinality 24 Table of Contents – Page ( xi ) Object-Oriented Data and Query Models 10.4 Scalar Method Data Type Checking 248 10.5 Arity Method Data Type Checking 251 10.6 Recursive Data Type Checking 253 10.7 F-Bounded Polymorphism 258 10.8 Data Type Checking & Inference in our Framework 259 10.9 Summary 260 11 Object-Oriented Query Model (I) 262 11.1 Basic Query
Load more

Recommended publications
  • Structured Recursion for Non-Uniform Data-Types
    Structured recursion for non-uniform data-types by Paul Alexander Blampied, B.Sc. Thesis submitted to the University of Nottingham for the degree of Doctor of Philosophy, March 2000 Contents Acknowledgements .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 1 Chapter 1. Introduction .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2 1.1. Non-uniform data-types .. .. .. .. .. .. .. .. .. .. .. .. 3 1.2. Program calculation .. .. .. .. .. .. .. .. .. .. .. .. .. 10 1.3. Maps and folds in Squiggol .. .. .. .. .. .. .. .. .. .. .. 11 1.4. Related work .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 14 1.5. Purpose and contributions of this thesis .. .. .. .. .. .. .. 15 Chapter 2. Categorical data-types .. .. .. .. .. .. .. .. .. .. .. .. 18 2.1. Notation .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 19 2.2. Data-types as initial algebras .. .. .. .. .. .. .. .. .. .. 21 2.3. Parameterized data-types .. .. .. .. .. .. .. .. .. .. .. 29 2.4. Calculation properties of catamorphisms .. .. .. .. .. .. .. 33 2.5. Existence of initial algebras .. .. .. .. .. .. .. .. .. .. .. 37 2.6. Algebraic data-types in functional programming .. .. .. .. 57 2.7. Chapter summary .. .. .. .. .. .. .. .. .. .. .. .. .. 61 Chapter 3. Folding in functor categories .. .. .. .. .. .. .. .. .. .. 62 3.1. Natural transformations and functor categories .. .. .. .. .. 63 3.2. Initial algebras in functor categories .. .. .. .. .. .. .. .. 68 3.3. Examples and non-examples .. .. .. .. .. .. .. .. .. .. 77 3.4. Existence of initial algebras in functor categories .. .. .. .. 82 3.5.
    [Show full text]
  • Binary Search Trees
    Introduction Recursive data types Binary Trees Binary Search Trees Organizing information Sum-of-Product data types Theory of Programming Languages Computer Science Department Wellesley College Introduction Recursive data types Binary Trees Binary Search Trees Table of contents Introduction Recursive data types Binary Trees Binary Search Trees Introduction Recursive data types Binary Trees Binary Search Trees Sum-of-product data types Every general-purpose programming language must allow the • processing of values with different structure that are nevertheless considered to have the same “type”. For example, in the processing of simple geometric figures, we • want a notion of a “figure type” that includes circles with a radius, rectangles with a width and height, and triangles with three sides: The name in the oval is a tag that indicates which kind of • figure the value is, and the branches leading down from the oval indicate the components of the value. Such types are known as sum-of-product data types because they consist of a sum of tagged types, each of which holds on to a product of components. Introduction Recursive data types Binary Trees Binary Search Trees Declaring the new figure type in Ocaml In Ocaml we can declare a new figure type that represents these sorts of geometric figures as follows: type figure = Circ of float (* radius *) | Rect of float * float (* width, height *) | Tri of float * float * float (* side1, side2, side3 *) Such a declaration is known as a data type declaration. It consists of a series of |-separated clauses of the form constructor-name of component-types, where constructor-name must be capitalized.
    [Show full text]
  • CS145 Lecture Notes #15 Introduction to OQL
    CS145 Lecture Notes #15 Introduction to OQL History Object-oriented DBMS (OODBMS) vendors hoped to take market share from traditional relational DBMS (RDBMS) vendors by offer- ing object-based data management Extend OO languages (C++, SmallTalk) with support for persis- tent objects RDBMS vendors responded by adding object support to relational systems (i.e., ORDBMS) and largely kept their customers OODBMS vendors have survived in another market niche: software systems that need some of their data to be persistent (e.g., CAD) Recall: ODMG: Object Database Management Group ODL: Object De®nition Language OQL: Object Query Language Query-Related Features of ODL Example: a student can take many courses but may TA at most one interface Student (extent Students, key SID) { attribute integer SID; attribute string name; attribute integer age; attribute float GPA; relationship Set<Course> takeCourses inverse Course::students; relationship Course assistCourse inverse Course::TAs; }; interface Course (extent Courses, key CID) { attribute string CID; attribute string title; relationship Set<Student> students inverse Student::takeCourses; relationship Set<Student> TAs inverse Student::assistCourse; }; Jun Yang 1 CS145 Spring 1999 For every class we can declare an extent, which is used to refer to the current collection of all objects of that class We can also declare methods written in the host language Basic SELECT Statement in OQL Example: ®nd CID and title of the course assisted by Lisa SELECT s.assistCourse.CID, s.assistCourse.title FROM Students
    [Show full text]
  • Recursive Type Generativity
    Recursive Type Generativity Derek Dreyer Toyota Technological Institute at Chicago [email protected] Abstract 1. Introduction Existential types provide a simple and elegant foundation for un- Recursive modules are one of the most frequently requested exten- derstanding generative abstract data types, of the kind supported by sions to the ML languages. After all, the ability to have cyclic de- the Standard ML module system. However, in attempting to extend pendencies between different files is a feature that is commonplace ML with support for recursive modules, we have found that the tra- in mainstream languages like C and Java. To the novice program- ditional existential account of type generativity does not work well mer especially, it seems very strange that the ML module system in the presence of mutually recursive module definitions. The key should provide such powerful mechanisms for data abstraction and problem is that, in recursive modules, one may wish to define an code reuse as functors and translucent signatures, and yet not allow abstract type in a context where a name for the type already exists, mutually recursive functions and data types to be broken into sepa- but the existential type mechanism does not allow one to do so. rate modules. Certainly, for simple examples of recursive modules, We propose a novel account of recursive type generativity that it is difficult to convincingly argue why ML could not be extended resolves this problem. The basic idea is to separate the act of gener- in some ad hoc way to allow them. However, when one considers ating a name for an abstract type from the act of defining its under- the semantics of a general recursive module mechanism, one runs lying representation.
    [Show full text]
  • EYEDB Object Query Language
    EYEDB Object Query Language Version 2.8.8 December 2007 Copyright c 1994-2008 SYSRA Published by SYSRA 30, avenue G´en´eral Leclerc 91330 Yerres - France home page: http://www.eyedb.org Contents 1 Introduction....................................... ............... 5 2 Principles ........................................ ............... 5 3 OQLvs.ODMG3OQL.................................... ........... 5 4 Language Concepts . ........... 7 5 Language Syntax . .......... 8 5.1 TerminalAtomSyntax.................................. .......... 8 5.2 Non Terminal Atom Production . 10 5.3 Keywords.......................................... 11 5.4 Comments.......................................... 11 5.5 Statements ........................................ 12 5.6 ExpressionStatements............................... 12 5.7 AtomicLiteralExpressions ............................ 14 5.8 ArithmeticExpressions ............................. 14 5.9 AssignmentExpressions .............................. 18 5.10 Auto Increment & Decrement Expressions . 19 5.11 Comparison Expressions . 20 5.12 Logical Expressions . 24 5.13 Conditional Expression . 24 5.14 ExpressionSequences ............................... 25 5.15 ArrayDeferencing ................................. 25 5.16 IdentifierExpressions .............................. 28 5.17 PathExpressions.................................... 32 5.18 FunctionCall....................................... 33 5.19 MethodInvocation................................... 34 5.20 Eval/Unval Operators . 37 5.21 SetExpressions...................................
    [Show full text]
  • Data Structures Are Ways to Organize Data (Informa- Tion). Examples
    CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 1 ] What are Data Structures? Data structures are ways to organize data (informa- tion). Examples: simple variables — primitive types objects — collection of data items of various types arrays — collection of data items of the same type, stored contiguously linked lists — sequence of data items, each one points to the next one Typically, algorithms go with the data structures to manipulate the data (e.g., the methods of a class). This course will cover some more complicated data structures: how to implement them efficiently what they are good for CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 2 ] Abstract Data Types An abstract data type (ADT) defines a state of an object and operations that act on the object, possibly changing the state. Similar to a Java class. This course will cover specifications of several common ADTs pros and cons of different implementations of the ADTs (e.g., array or linked list? sorted or unsorted?) how the ADT can be used to solve other problems CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 3 ] Specific ADTs The ADTs to be studied (and some sample applica- tions) are: stack evaluate arithmetic expressions queue simulate complex systems, such as traffic general list AI systems, including the LISP language tree simple and fast sorting table database applications, with quick look-up CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 4 ] How Does C Fit In? Although data structures are universal (can be imple- mented in any programming language), this course will use Java and C: non-object-oriented parts of Java are based on C C is not object-oriented We will learn how to gain the advantages of data ab- straction and modularity in C, by using self-discipline to achieve what Java forces you to do.
    [Show full text]
  • SOQL and SOSL Reference
    SOQL and SOSL Reference Version 53.0, Winter ’22 @salesforcedocs Last updated: August 26, 2021 © Copyright 2000–2021 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of salesforce.com, inc., as are other names and marks. Other marks appearing herein may be trademarks of their respective owners. CONTENTS Chapter 1: Introduction to SOQL and SOSL . 1 Chapter 2: Salesforce Object Query Language (SOQL) . 3 Typographical Conventions in This Document . 5 Quoted String Escape Sequences . 5 Reserved Characters . 6 Alias Notation . 7 SOQL SELECT Syntax . 7 Condition Expression Syntax (WHERE Clause) . 9 fieldExpression Syntax . 13 USING SCOPE . 26 ORDER BY . 27 LIMIT . 28 OFFSET . 29 FIELDS() . 31 Update an Article’s Keyword Tracking with SOQL . 35 Update an Article Viewstat with SOQL . 35 WITH filteringExpression . 35 GROUP BY . 40 HAVING . 47 TYPEOF . 48 FORMAT () . 51 FOR VIEW . 51 FOR REFERENCE . 52 FOR UPDATE . 52 Aggregate Functions . 53 Date Functions . 58 Querying Currency Fields in Multi-Currency Orgs . 60 Example SELECT Clauses . 62 Relationship Queries . 63 Understanding Relationship Names . 64 Using Relationship Queries . 65 Understanding Relationship Names, Custom Objects, and Custom Fields . 66 Understanding Query Results . 68 Lookup Relationships and Outer Joins . 70 Identifying Parent and Child Relationships . 70 Understanding Relationship Fields and Polymorphic Fields . 72 Understanding Relationship Query Limitations . 77 Using Relationship Queries with History Objects . 77 Contents Using Relationship Queries with Data Category Selection Objects . 78 Using Relationship Queries with the Partner WSDL . 78 Change the Batch Size in Queries . 78 SOQL Limits on Objects . 79 SOQL with Big Objects . 83 Syndication Feed SOQL and Mapping Syntax .
    [Show full text]
  • Query Service Specification
    Query Service Specification Version 1.0 New Edition: April 2000 Copyright 1999, FUJITSU LIMITED Copyright 1999, INPRISE Corporation Copyright 1999, IONA Technologies PLC Copyright 1999, Objectivity Inc. Copyright 1991, 1992, 1995, 1996, 1999 Object Management Group, Inc. Copyright 1999, Oracle Corporation Copyright 1999, Persistence Software Inc. Copyright 1999, Secant Technologies Inc. Copyright 1999, Sun Microsystems Inc. The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. PATENT The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. NOTICE The information contained in this document is subject to change without notice. The material in this document details an Object Management Group specification in accordance with the license and notices set forth on this page.
    [Show full text]
  • Recursive Type Generativity
    JFP 17 (4 & 5): 433–471, 2007. c 2007 Cambridge University Press 433 doi:10.1017/S0956796807006429 Printed in the United Kingdom Recursive type generativity DEREK DREYER Toyota Technological Institute, Chicago, IL 60637, USA (e-mail: [email protected]) Abstract Existential types provide a simple and elegant foundation for understanding generative abstract data types of the kind supported by the Standard ML module system. However, in attempting to extend ML with support for recursive modules, we have found that the traditional existential account of type generativity does not work well in the presence of mutually recursive module definitions. The key problem is that, in recursive modules, one may wish to define an abstract type in a context where a name for the type already exists, but the existential type mechanism does not allow one to do so. We propose a novel account of recursive type generativity that resolves this problem. The basic idea is to separate the act of generating a name for an abstract type from the act of defining its underlying representation. To define several abstract types recursively, one may first “forward-declare” them by generating their names, and then supply each one’s identity secretly within its own defining expression. Intuitively, this can be viewed as a kind of backpatching semantics for recursion at the level of types. Care must be taken to ensure that a type name is not defined more than once, and that cycles do not arise among “transparent” type definitions. In contrast to the usual continuation-passing interpretation of existential types in terms of universal types, our account of type generativity suggests a destination-passing interpretation.
    [Show full text]
  • Compositional Data Types
    Compositional Data Types Patrick Bahr Tom Hvitved Department of Computer Science, University of Copenhagen Universitetsparken 1, 2100 Copenhagen, Denmark {paba,hvitved}@diku.dk Abstract require the duplication of functions which work both on general and Building on Wouter Swierstra’s Data types `ala carte, we present a non-empty lists. comprehensive Haskell library of compositional data types suitable The situation illustrated above is an ubiquitous issue in com- for practical applications. In this framework, data types and func- piler construction: In a compiler, an abstract syntax tree (AST) tions on them can be defined in a modular fashion. We extend the is produced from a source file, which then goes through different existing work by implementing a wide array of recursion schemes transformation and analysis phases, and is finally transformed into including monadic computations. Above all, we generalise recur- the target code. As functional programmers, we want to reflect the sive data types to contexts, which allow us to characterise a special changes of each transformation step in the type of the AST. For ex- yet frequent kind of catamorphisms. The thus established notion of ample, consider the desugaring phase of a compiler which reduces term homomorphisms allows for flexible reuse and enables short- syntactic sugar to the core syntax of the object language. To prop- cut fusion style deforestation which yields considerable speedups. erly reflect this structural change also in the types, we have to create We demonstrate our framework in the setting of compiler con- and maintain a variant of the data type defining the AST for the core struction, and moreover, we compare compositional data types with syntax.
    [Show full text]
  • 4. Types and Polymorphism
    4. Types and Polymorphism Oscar Nierstrasz Static types ok Semantics ok Syntax ok Program text Roadmap > Static and Dynamic Types > Type Completeness > Types in Haskell > Monomorphic and Polymorphic types > Hindley-Milner Type Inference > Overloading References > Paul Hudak, “Conception, Evolution, and Application of Functional Programming Languages,” ACM Computing Surveys 21/3, Sept. 1989, pp 359-411. > L. Cardelli and P. Wegner, “On Understanding Types, Data Abstraction, and Polymorphism,” ACM Computing Surveys, 17/4, Dec. 1985, pp. 471-522. > D. Watt, Programming Language Concepts and Paradigms, Prentice Hall, 1990 3 Conception, Evolution, and Application of Functional Programming Languages http://scgresources.unibe.ch/Literature/PL/Huda89a-p359-hudak.pdf On Understanding Types, Data Abstraction, and Polymorphism http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf Roadmap > Static and Dynamic Types > Type Completeness > Types in Haskell > Monomorphic and Polymorphic types > Hindley-Milner Type Inference > Overloading What is a Type? Type errors: ? 5 + [ ] ERROR: Type error in application *** expression : 5 + [ ] *** term : 5 *** type : Int *** does not match : [a] A type is a set of values? > int = { ... -2, -1, 0, 1, 2, 3, ... } > bool = { True, False } > Point = { [x=0,y=0], [x=1,y=0], [x=0,y=1] ... } 5 The notion of a type as a set of values is very natural and intuitive: Integers are a set of values; the Java type JButton corresponds to all possible instance of the JButton class (or any of its possible subclasses). What is a Type? A type is a partial specification of behaviour? > n,m:int ⇒ n+m is valid, but not(n) is an error > n:int ⇒ n := 1 is valid, but n := “hello world” is an error What kinds of specifications are interesting? Useful? 6 A Java interface is a simple example of a partial specification of behaviour.
    [Show full text]
  • Computing Lectures
    Computing Lectures 1 R Basics Introduction to computing/programming using slides. Using R as a pocket calculator: • arithmetic operators (+, -, *, /, and ^) • elementary functions (exp and log, sin and cos) • Inf and NaN • pi and options(digits) • comparison operators (>, >=, <, <=, ==, !=): informally introduce logicals which will be discussed in more detail in unit 2. Using variables: • assignment using <- (\gets"): binding symbols to values) • inspect the binding (show the value of an object) by typing the symbol (name of the object): auto-prints. Show that explicitly calling print() has the same effect. • inspect available bindings (list objects) using ls() or objects() • remove bindings (\delete objects") using rm() Using sequences: • sequences, also known as vectors, can be combined using c() • functions seq() and rep() allow efficient creation of certain patterned sequences; shortcut : • subsequences can be selected by subscripting via [, using positive (numeric) indices (positions of elements to select) or negative indices (positions of elements to drop) • can compute with whole sequences: vectorization • summary functions: sum, prod, max, min, range • can also have sequences of character strings • sequences can also have names: use R> x <- c(A = 1, B = 2, C = 3) R> names(x) [1] "A" "B" "C" R> ## Change the names. R> names(x) <- c("d", "e", "f") R> x 1 d e f 1 2 3 R> ## Remove the names. R> names(x) <- NULL R> x [1] 1 2 3 for extracting and replacing the names, aka as getting and setting Using functions: • start with the simple standard example R> hell <- function() writeLines("Hello world.") to explain the constituents of functions: argument list (formals), body, and environment.
    [Show full text]