Arity-Generic Datatype-Generic Programming

Total Page:16

File Type:pdf, Size:1020Kb

Arity-Generic Datatype-Generic Programming Arity-Generic Datatype-Generic Programming Chris Casinghino Stephanie Weirich University of Pennsylvania January 19, 2010 PLPV, Madrid 1/32 Outline 1 Motivation 2 Arities in Datatype-Generic Programming 3 A Universe for Generic Programming 4 The Framework 5 Arity-Generic Map 6 Conclusion 2/32 Datatype-Genericity Datatype-generic functions can be implemented for many datatypes. list-map :(a ! b) ! [a] ! [b] maybe-map :(a ! b) ! Maybea ! Maybeb pair-map :(a1 ! a2) ! (b1 ! b2) ! (a1; b1) ! (a2; b2) 3/32 Arity-Genericity Arity-generic functions can be implemented at many arities. At higher arities, map is often called zip. The Haskell standard library includes: repeat : a ! [a] map :(a ! b) ! [a] ! [b] zipWith :(a ! b ! c) ! [a] ! [b] ! [c] zipWith3 :(a ! b ! c ! d) ! [a] ! [b] ! [c] ! [d] 4/32 Doubly Generic Functions • Some functions, like map, are doubly generic. pair-map1 : a1 ! a2 ! (a1; a2) maybe-map2 :(a ! b) ! Maybea ! Maybeb list-map3 :(a ! b ! c) ! [a] ! [b] ! [c] ... • Goal: one function, ngmap, which produces any of these denitions from an arity and a type. For example: ngmap2 Maybe :(a ! b) ! Maybea ! Maybeb • Importantly, the notion of arity already appears in datatype-generic programming (but not arity-genericity). 5/32 Motivation Why study doubly generic functions? • They can reduce boilerplate. • We may be able to prove properties generally for all instances of doubly generic functions. • New insight into the nature of operations like map. • Formally specifying a framework for them helps us nd more. 6/32 Outline 1 Motivation 2 Arities in Datatype-Generic Programming 3 A Universe for Generic Programming 4 The Framework 5 Arity-Generic Map 6 Conclusion 7/32 Dierent Types at Dierent Kinds • Consider equality functions for various types: nat-eq : N ! N ! Bool list-eq : 8 a : (a ! a ! Bool) ! [a] ! [a] ! Bool pair-eq : 8 ab : (a ! a ! Bool) ! (b ! b ! Bool) ! (a; b) ! (a; b) ! Bool • Generic Haskell style datatype-generic programs have kind-indexed types. Eq h?i t = t ! t ! Bool Eq hk1 ) k2i t = 8 a : Eq hk1i a ! Eq hk2i (ta ) • The kind-indexed type Eq has arity one, because it takes one type argument. 8/32 Kind-indexed Types for Maps • On the other hand, datatype-generic map has a kind-indexed type of arity two. Map h?i t1 t2 = t1 ! t2 Map hk1 ) k2i t1 t2 = 8 ab : Map hk1i ab ! Map hk2i (t1 a)(t2 b) • Datatype-generic zipWith has a kind-indexed type of arity three. Zip h?i t1 t2 t3 = t1 ! t2 ! t3 Zip hk1 ) k2i t1 t2 t3 = 8 abc : Zip hk1i abc ! Zip hk2i (t1 a)(t2 b)(t3 c) • These two look very similar... 9/32 Summary • Arities already show up in standard kind-indexed types. • Some frameworks for datatype-generic programming support dierent arities (but not generalizing over the arity). • New observation: when written in dependently-typed languages, they can support arity-genericity too. 10/32 Outline 1 Motivation 2 Arities in Datatype-Generic Programming 3 A Universe for Generic Programming 4 The Framework 5 Arity-Generic Map 6 Conclusion 11/32 Universes • In dependently typed languages (like Agda), generic programming frameworks are implemented using universes. • A universe is: • A data structure to represent part of the type language • And an interpretation function to convert members of the datatype to actual Agda types. • A generic program is dened by recursion over the universe. • Our universe is based on the type language of F !it's essentially STLC. 12/32 Kinds • We dene a data type to represent kinds, and a function to interpret its members (the codes) as Agda kinds. data Kind : Set where ? : Kind _)_ : Kind ! Kind ! Kind _ : Kind ! Set J ?K = Set J a )K b = a ! b J K J K J K • Set is the classier of Agda types. We'll gloss over some details of the type hierarchy. 13/32 Type Constants Type constants are indexed by their kinds. data Const : Kind ! Set where Unit : Const ? Nat : Const ? Sum : Const (? ) ? ) ?) Prod : Const (? ) ? ) ?) interp-c : 8f kg! Constk ! k interp-c Unit = > J K interp-c Nat = N interp-c Sum = _]_ interp-c Prod = _×_ 14/32 Types • Types comprise variables, functions, applications, and constants. data Ty : Ctx ! Kind ! Set where Var : ... Lam : ... App : ... Con : ... • We have a function for interpreting closed Types: b_c : 8f kg! Ty [] k ! k J K 15/32 Example • As an example, we might dene an Option type in Agda, isomorphic to the standard datatype: Option : Set ! Set Option = λ A !>] A • We can represent it with a code: option : Ty [](? ) ?) option = Lam (App (App (Con Sum)(Con Unit)) (VarVZ )) • Agda can see that b option c normalizes to Option. 16/32 Outline 1 Motivation 2 Arities in Datatype-Generic Programming 3 A Universe for Generic Programming 4 The Framework 5 Arity-Generic Map 6 Conclusion 17/32 Preliminaries • We need just two more things. • Agda's library has length indexed vectors: data Vec (A : Set): N ! Set where []: VecA zero _::_ : 8f ng (a : A)(xs : VecAn ) ! VecA (sucn ) • We dene_ ~_, pronounced zap, a zipping application on vectors: _~_ : fAB : Setg fn : Ng ! Vec (A ! B) n ! VecAn ! VecBn • And repeat, which createsn copies of a term: repeat : fA : Setg! (n : N) ! A ! VecAn 18/32 Kind-indexed Types revisited • Observe that the kind-indexed types we saw before have a very regular form: Eq h?i t = t ! t ! Bool Eq hk1 ) k2i t = 8 a : Eq hk1i a ! Eq hk2i (ta ) Map h?i t1 t2 = t1 ! t2 Map hk1 ) k2i t1 t2 = 8 ab : Map hk1i ab ! Map hk2i (t1 a)(t2 b) • At kind ?, they use the type argument(s) in an operation-specic way. • At arrow kinds they are logical and completely regular. 19/32 Kind-indexed Types, formally • So, we can derive instances of kind-indexed types automatically if provided with the denition at base kinds: _h_i_ : fn : Ng! (b : Vec Setn ! Set) ! (k : Kind) ! Vec k n ! Set J K b h ? i v = bv b h k1 ) k2 i v = (a : Vec k1 ) ! b h k1 i a ! b h k2 i (v ~ a) J K • Since the number of type arguments is variable, we take them as a vector. • In the development, this denition is then curried so users can supply the types individually. 20/32 Example: GMap • Datatype-generic map has arity two. Its base type is: GMap :(v : Vec Set2 ) ! Set GMap (A::B:: [ ]) = A ! B • GMap h? ) ?i (repeat2 List ) normalizes to: 8f AB : Setg! (A ! B) ! ListA ! ListB • GMap h? ) ? ) ?i (repeat2_ ×_) normalizes to: 8f A1 B1 : Setg! (A1 ! B1) !f A2 B2 : Setg! (A2 ! B2) ! (A1 × A2) ! (B1 × B2) 21/32 The Framework • Users implement the operation for type constants by constructing a TyConstEnvb TyConstEnvb = fk : Kindg (c : Constk ) ! b h k i (repeat b Conc c) • Then they call ngen: ngen : fn : Ng fb : Vec Setn ! Setg fk : Kindg ! (TyConstEnvb ) ! (t : Ty [] k) ! b h k i (repeatn b t c) 22/32 Map's TyConstEnv • We've already dened datatype-generic map's type. • Now, its TyConstEnv. gmap-const : TyConstEnv GMap gmap-const Nat = λ x ! x gmap-const Unit = λ x ! x gmap-const Prod = λ f1 f2x ! (f1 (proj1 x); f2 (proj2 x)) gmap-const Sum = g where g : fA1 B1 A2B2 : Setg ! (A1 ! B1) ! (A2 ! B2) ! A1 ] A2 ! B1 ] B2 g fa fb (inj1 xa) = inj1 (fa xa) g fa fb (inj2 xb) = inj2 (fb xb) 23/32 Datatype-Generic Map • With gmap-const, we can dene datatype-generic map: gmap : fk : Kindg! (t : Ty [] k) ! GMap h k i (b t c :: b t c :: [ ]) gmapt = ngen gmap-constt • For example: option-map : fAB : Setg! (A ! B) ! OptionA ! OptionB option-map = gmap option • Using generic functions at actual Agda datatypes is discussed in the paper. 24/32 Outline 1 Motivation 2 Arities in Datatype-Generic Programming 3 A Universe for Generic Programming 4 The Framework 5 Arity-Generic Map 6 Conclusion 25/32 Writing Arity-Generic Programs • All the pieces of the framework are parameterized by arity: _h_i_ : fn : Ng! (b : Vec Setn ! Set) ! (k : Kind) ! Vec k n ! Set J K TyConstEnv : fn : Ng! (b : Vec Setn ! Set) ! Set ngen : fn : Ng fb : Vec Setn ! Setg fk : Kindg ! (TyConstEnvb ) ! (t : Ty [] k) ! b h k i (repeatn b t c)) • So, if we deneb and the TyConstEnv while leaving the arity general, we can get out an arity-generic denition. 26/32 Arity-Generic Map • So, we want to dene arity-generic map's base type and TyConstEnv for any arity: NGmap : fn : Ng! Vec Setn ! Set NGmap Ts = see the paper! ngmap-const : fn : Ng! TyConstEnv fng NGmap ngmap-const fng c = see the paper! • With these, we can get arity-generic map directly from ngen. ngmap : fk : Kindg! (n : N) ! (t : Ty [] k) ! NGmap h k i (repeatn b t c) ngmapnt = ngen ngmap-constt 27/32 Examples with ngmap For example, maps and zips on products are instances of ngmap: pair-map1 : fAB : Setg! A ! B ! A × B pair-map1 = ngmap1 (Con Prod) pair-map2 : fA1 B1 A2B2 : Setg ! (A1 ! B1) ! (A2 ! B2) ! A1 × A2 ! B1 × B2 pair-map2 = ngmap2 (Con Prod) pair-map3 : fA1 B1 C1 A2 B2 C2 : Setg ! (A1 ! B1 ! C1) ! (A2 ! B2 ! C2) ! A1 × A2 ! B1 × B2 ! C1 × C2 pair-map3 = ngmap3 (Con Prod) 28/32 Outline 1 Motivation 2 Arities in Datatype-Generic Programming 3 A Universe for Generic Programming 4 The Framework 5 Arity-Generic Map 6 Conclusion 29/32 Conclusion Also in the paper: • More arity-generic programs (equality, unzip, folds).
Recommended publications
  • A Call-By-Need Lambda Calculus
    A CallByNeed Lamb da Calculus Zena M Ariola Matthias Fel leisen Computer Information Science Department Department of Computer Science University of Oregon Rice University Eugene Oregon Houston Texas John Maraist and Martin Odersky Philip Wad ler Institut fur Programmstrukturen Department of Computing Science Universitat Karlsruhe UniversityofGlasgow Karlsruhe Germany Glasgow Scotland Abstract arguments value when it is rst evaluated More pre cisely lazy languages only reduce an argument if the The mismatchbetween the op erational semantics of the value of the corresp onding formal parameter is needed lamb da calculus and the actual b ehavior of implemen for the evaluation of the pro cedure b o dy Moreover af tations is a ma jor obstacle for compiler writers They ter reducing the argument the evaluator will remember cannot explain the b ehavior of their evaluator in terms the resulting value for future references to that formal of source level syntax and they cannot easily com parameter This technique of evaluating pro cedure pa pare distinct implementations of dierent lazy strate rameters is called cal lbyneed or lazy evaluation gies In this pap er we derive an equational characteri A simple observation justies callbyneed the re zation of callbyneed and prove it correct with resp ect sult of reducing an expression if any is indistinguish to the original lamb da calculus The theory is a strictly able from the expression itself in all p ossible contexts smaller theory than the lamb da calculus Immediate Some implementations attempt
    [Show full text]
  • Chapter 5 Type Declarations
    Ch.5: Type Declarations Plan Chapter 5 Type Declarations (Version of 27 September 2004) 1. Renaming existing types . 5.2 2. Enumeration types . 5.3 3. Constructed types . 5.5 4. Parameterised/polymorphic types . 5.10 5. Exceptions, revisited . 5.12 6. Application: expression evaluation . 5.13 °c P. Flener/IT Dept/Uppsala Univ. FP 5.1 Ch.5: Type Declarations 5.1. Renaming existing types 5.1. Renaming existing types Example: polynomials, revisited Representation of a polynomial by a list of integers: type poly = int list ² Introduction of an abbreviation for the type int list ² The two names denote the same type ² The object [4,2,8] is of type poly and of type int list - type poly = int list ; type poly = int list - type poly2 = int list ; type poly2 = int list - val p:poly = [1,2] ; val p = [1,2] : poly - val p2:poly2 = [1,2] ; val p2 = [1,2] : poly2 - p = p2 ; val it = true : bool °c P. Flener/IT Dept/Uppsala Univ. FP 5.2 Ch.5: Type Declarations 5.2. Enumeration types 5.2. Enumeration types Declaration of a new type having a finite number of values Example (weekend.sml) datatype months = Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec datatype days = Mon | Tue | Wed | Thu | Fri | Sat | Sun fun weekend Sat = true | weekend Sun = true | weekend d = false - datatype months = Jan | ... | Dec ; datatype months = Jan | ... | Dec - datatype days = Mon | ... | Sun ; datatype days = Mon | ... | Sun - fun weekend ... ; val weekend = fn : days -> bool °c P. Flener/IT Dept/Uppsala Univ. FP 5.3 Ch.5: Type Declarations 5.2.
    [Show full text]
  • Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019
    Nominal Wyvern: Employing Semantic Separation for Usability Yu Xiang Zhu CMU-CS-19-105 April 2019 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Jonathan Aldrich, Chair Heather Miller Alex Potanin, Victoria University of Wellington, NZ Submitted in partial fulfillment of the requirements for the degree of Master of Science. Copyright c 2019 Yu Xiang Zhu Keywords: Nominality, Wyvern, Dependent Object Types, Subtype Decidability Abstract This thesis presents Nominal Wyvern, a nominal type system that empha- sizes semantic separation for better usability. Nominal Wyvern is based on the dependent object types (DOT) calculus, which provides greater expressiv- ity than traditional object-oriented languages by incorporating concepts from functional languages. Although DOT is generally perceived to be nominal due to its path-dependent types, it is still a mostly structural system and relies on the free construction of types. This can present usability issues in a subtyping- based system where the semantics of a type are as important as its syntactic structure. Nominal Wyvern overcomes this problem by semantically separat- ing structural type/subtype definitions from ad hoc type refinements and type bound declarations. In doing so, Nominal Wyvern is also able to overcome the subtype undecidability problem of DOT by adopting a semantics-based sep- aration between types responsible for recursive subtype definitions and types that represent concrete data. The result is a more intuitive type system that achieves nominality and decidability while maintaining the expressiveness of F-bounded polymorphism that is used in practice. iv Acknowledgments This research would not have been possible without the support from the following in- dividuals.
    [Show full text]
  • Cablelabs® Specifications Cablelabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317
    CableLabs® Specifications CableLabs' DHCP Options Registry CL-SP-CANN-DHCP-Reg-I13-160317 ISSUED Notice This CableLabs specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. You may download, copy, distribute, and reference the documents herein only for the purpose of developing products or services in accordance with such documents, and educational use. Except as granted by CableLabs in a separate written license agreement, no license is granted to modify the documents herein (except via the Engineering Change process), or to use, copy, modify or distribute the documents for any other purpose. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. To the extent this document contains or refers to documents of third parties, you agree to abide by the terms of any licenses associated with such third-party documents, including open source licenses, if any. Cable Television Laboratories, Inc. 2006-2016 CL-SP-CANN-DHCP-Reg-I13-160317 CableLabs® Specifications DISCLAIMER This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein. Any use or reliance on the information or opinion in this document is at the risk of the user, and CableLabs and its members shall not be liable for any damage or injury incurred by any person arising out of the completeness, accuracy, or utility of any information or opinion contained in the document.
    [Show full text]
  • NU-Prolog Reference Manual
    NU-Prolog Reference Manual Version 1.5.24 edited by James A. Thom & Justin Zobel Technical Report 86/10 Machine Intelligence Project Department of Computer Science University of Melbourne (Revised November 1990) Copyright 1986, 1987, 1988, Machine Intelligence Project, The University of Melbourne. All rights reserved. The Technical Report edition of this publication is given away free subject to the condition that it shall not, by the way of trade or otherwise, be lent, resold, hired out, or otherwise circulated, without the prior consent of the Machine Intelligence Project at the University of Melbourne, in any form or cover other than that in which it is published and without a similar condition including this condition being imposed on the subsequent user. The Machine Intelligence Project makes no representations or warranties with respect to the contents of this document and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, the Machine Intelligence Project reserves the right to revise this document and to make changes from time to time in its content without being obligated to notify any person or body of such revisions or changes. The usual codicil that no part of this publication may be reproduced, stored in a retrieval system, used for wrapping fish, or transmitted, in any form or by any means, electronic, mechanical, photocopying, paper dart, recording, or otherwise, without someone's express permission, is not imposed. Enquiries relating to the acquisition of NU-Prolog should be made to NU-Prolog Distribution Manager Machine Intelligence Project Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia Telephone: (03) 344 5229.
    [Show full text]
  • Variable-Arity Generic Interfaces
    Variable-Arity Generic Interfaces T. Stephen Strickland, Richard Cobbe, and Matthias Felleisen College of Computer and Information Science Northeastern University Boston, MA 02115 [email protected] Abstract. Many programming languages provide variable-arity func- tions. Such functions consume a fixed number of required arguments plus an unspecified number of \rest arguments." The C++ standardiza- tion committee has recently lifted this flexibility from terms to types with the adoption of a proposal for variable-arity templates. In this paper we propose an extension of Java with variable-arity interfaces. We present some programming examples that can benefit from variable-arity generic interfaces in Java; a type-safe model of such a language; and a reduction to the core language. 1 Introduction In April of 2007 the C++ standardization committee adopted Gregor and J¨arvi's proposal [1] for variable-length type arguments in class templates, which pre- sented the idea and its implementation but did not include a formal model or soundness proof. As a result, the relevant constructs will appear in the upcom- ing C++09 draft. Demand for this feature is not limited to C++, however. David Hall submitted a request for variable-arity type parameters for classes to Sun in 2005 [2]. For an illustration of the idea, consider the remarks on first-class functions in Scala [3] from the language's homepage. There it says that \every function is a value. Scala provides a lightweight syntax for defining anonymous functions, it supports higher-order functions, it allows functions to be nested, and supports currying." To achieve this integration of objects and closures, Scala's standard library pre-defines ten interfaces (traits) for function types, which we show here in Java-like syntax: interface Function0<Result> { Result apply(); } interface Function1<Arg1,Result> { Result apply(Arg1 a1); } interface Function2<Arg1,Arg2,Result> { Result apply(Arg1 a1, Arg2 a2); } ..
    [Show full text]
  • Small Hitting-Sets for Tiny Arithmetic Circuits Or: How to Turn Bad Designs Into Good
    Electronic Colloquium on Computational Complexity, Report No. 35 (2017) Small hitting-sets for tiny arithmetic circuits or: How to turn bad designs into good Manindra Agrawal ∗ Michael Forbes† Sumanta Ghosh ‡ Nitin Saxena § Abstract Research in the last decade has shown that to prove lower bounds or to derandomize polynomial identity testing (PIT) for general arithmetic circuits it suffices to solve these questions for restricted circuits. In this work, we study the smallest possibly restricted class of circuits, in particular depth-4 circuits, which would yield such results for general circuits (that is, the complexity class VP). We show that if we can design poly(s)-time hitting-sets for Σ ∧a ΣΠO(log s) circuits of size s, where a = ω(1) is arbitrarily small and the number of variables, or arity n, is O(log s), then we can derandomize blackbox PIT for general circuits in quasipolynomial time. Further, this establishes that either E6⊆#P/poly or that VP6=VNP. We call the former model tiny diagonal depth-4. Note that these are merely polynomials with arity O(log s) and degree ω(log s). In fact, we show that one only needs a poly(s)-time hitting-set against individual-degree a′ = ω(1) polynomials that are computable by a size-s arity-(log s) ΣΠΣ circuit (note: Π fanin may be s). Alternatively, we claim that, to understand VP one only needs to find hitting-sets, for depth-3, that have a small parameterized complexity. Another tiny family of interest is when we restrict the arity n = ω(1) to be arbitrarily small.
    [Show full text]
  • Project Overview 1 Introduction 2 a Quick Introduction to SOOL
    CMSC 22600 Compilers for Computer Languages Handout 1 Autumn 2016 October 6, 2016 Project Overview 1 Introduction The project for the course is to implement a small object-oriented programming language, called SOOL. The project will consist of four parts: 1. the parser and scanner, which coverts a textual representation of the program into a parse tree representation. 2. the type checker, which checks the parse tree for type correctness and produces a typed ab- stract syntax tree (AST) 3. the normalizer, which converts the typed AST representation into a static single-assignment (SSA) representation. 4. the code generator, which takes the SSA representation and generates LLVM assembly code. Each part of the project builds upon the previous parts, but we will provide reference solutions for previous parts. You will implement the project in the Standard ML programming language and submission of the project milestones will be managed using Phoenixforge. Important note: You are expected to submit code that compiles and that is well documented. Points for project code are assigned 30% for coding style (documentation, choice of variable names, and program structure), and 70% for correctness. Code that does not compile will not receive any points for correctness. 2 A quick introduction to SOOL SOOL is a statically-typed object-oriented language. It supports single inheritance with nominal subtyping and interfaces with structural subtyping. The SOOL version of the classic Hello World program is class main () { meth run () -> void { system.print ("hello world\n"); } } Here we are using the predefined system object to print the message. Every SOOL program has a main class that must have a run function.
    [Show full text]
  • Making a Faster Curry with Extensional Types
    Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004].
    [Show full text]
  • Lambda-Calculus Types and Models
    Jean-Louis Krivine LAMBDA-CALCULUS TYPES AND MODELS Translated from french by René Cori To my daughter Contents Introduction5 1 Substitution and beta-conversion7 Simple substitution ..............................8 Alpha-equivalence and substitution ..................... 12 Beta-conversion ................................ 18 Eta-conversion ................................. 24 2 Representation of recursive functions 29 Head normal forms .............................. 29 Representable functions ............................ 31 Fixed point combinators ........................... 34 The second fixed point theorem ....................... 37 3 Intersection type systems 41 System D­ ................................... 41 System D .................................... 50 Typings for normal terms ........................... 54 4 Normalization and standardization 61 Typings for normalizable terms ........................ 61 Strong normalization ............................. 68 ¯I-reduction ................................. 70 The ¸I-calculus ................................ 72 ¯´-reduction ................................. 74 The finite developments theorem ....................... 77 The standardization theorem ......................... 81 5 The Böhm theorem 87 3 4 CONTENTS 6 Combinatory logic 95 Combinatory algebras ............................. 95 Extensionality axioms ............................. 98 Curry’s equations ............................... 101 Translation of ¸-calculus ........................... 105 7 Models of lambda-calculus 111 Functional
    [Show full text]
  • An Introduction to Lean
    An Introduction to Lean Jeremy Avigad Leonardo de Moura Gabriel Ebner and Sebastian Ullrich Version 1fc176a, updated at 2017-01-09 14:16:26 -0500 2 Contents Contents 3 1 Overview 5 1.1 Perspectives on Lean ............................... 5 1.2 Where To Go From Here ............................. 12 2 Defining Objects in Lean 13 2.1 Some Basic Types ................................ 14 2.2 Defining Functions ................................ 17 2.3 Defining New Types ............................... 20 2.4 Records and Structures ............................. 22 2.5 Nonconstructive Definitions ........................... 25 3 Programming in Lean 27 3.1 Evaluating Expressions .............................. 28 3.2 Recursive Definitions ............................... 30 3.3 Inhabited Types, Subtypes, and Option Types . 32 3.4 Monads ...................................... 34 3.5 Input and Output ................................ 35 3.6 An Example: Abstract Syntax ......................... 36 4 Theorem Proving in Lean 38 4.1 Assertions in Dependent Type Theory ..................... 38 4.2 Propositions as Types .............................. 39 4.3 Induction and Calculation ............................ 42 4.4 Axioms ...................................... 45 5 Using Automation in Lean 46 6 Metaprogramming in Lean 47 3 CONTENTS 4 Bibliography 48 1 Overview This introduction offers a tour of Lean and its features, with a number of examples foryou to play around with and explore. If you are reading this in our online tutorial system, you can run examples like the one below by clicking the button that says “try it yourself.” #check "hello world!" The response from Lean appears in the small window underneath the editor text, and also in popup windows that you can read when you hover over the indicators in the left margin. Alternatively, if you have installed Lean and have it running in a stand-alone editor, you can copy and paste examples and try them there.
    [Show full text]
  • Formats and Protocols for Continuous Data CD-1.1
    IDC Software documentation Formats and Protocols for Continuous Data CD-1.1 Document Version: 0.3 Document Edition: English Document Status: Final Document ID: IDC 3.4.3 Document Date: 18 December 2002 IDC Software documentation Formats and Protocols for Continuous Data CD-1.1 Version: 0.3 Notice This document was published December 2002 as Revision 0.3, using layout templates established by the IPT Group of CERN and IDC Corporate Style guidelines. This document is a re-casting of Revision 0.2published in December 2001 as part of the International Data Centre (IDC) Documentation. It was first published in July 2000 and was repub- lished electronically as Revision 0.1 in September 2001 and as Revision 0.2 in December 2001 to include minor changes (see the following Change Page for Revision 0.2). IDC documents that have been changed substantially are indicated by a whole revision number (for example, Revision 1). Trademarks IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc. Motorola is a registered trademark of Motorola Inc. SAIC is a trademark of Science Applications International Corporation. Sun is a registered trademark of Sun Microsystems. UNIX is a registered trademark of UNIX System Labs, Inc. This document has been prepared using the Software Documentation Layout Templates that have been prepared by the IPT Group (Information, Process and Technology), IT Division, CERN (The European Laboratory for Particle Physics). For more information, go to http://framemaker.cern.ch/. page ii Final Abstract Version: 0.3 Abstract This document describes the formats and protocols of Continuous Data (CD-1.1), a standard to be used for transmitting continuous, time series data from stations of the International Monitoring System (IMS) to the International Data Centre (IDC) and for transmitting these data from the IDC to National Data Centers (NDCs).
    [Show full text]