DOCSLIB.ORG

Advanced Functional Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Advanced Functional Programming Advanced Functional Programming Páli, Gábor János Horváth, Zoltán Created by XMLmind XSL-FO Converter. Advanced Functional Programming írta Páli, Gábor János és Horváth, Zoltán Publication date 2014 Szerzői jog © 2014 Páli Gábor János, Horváth Zoltán Created by XMLmind XSL-FO Converter. Tartalom Advanced Functional Programming ................................................................................................... 1 1. 1 Syllabus .............................................................................................................................. 1 1.1. Highlights of the Curriculum .................................................................................... 1 2. 2 Motivation .......................................................................................................................... 1 2.1. Why Functional Programming? ................................................................................ 2 2.2. Functional Languages Used Out There .................................................................... 2 3. 3 Literature ............................................................................................................................ 2 3.1. Recommended Reading ............................................................................................ 2 3.2. Recommended Reading ............................................................................................ 2 4. 4 Introduction ........................................................................................................................ 2 4.1. Purely Functional Languages ................................................................................... 3 4.2. Elements of a Functional-Language Type System ................................................... 3 4.3. Recap: Type Checking .............................................................................................. 3 4.4. Recap: Type Definitions, Annotations ...................................................................... 3 4.5. Recap: Parametric and "Ad Hoc" Polymorphism ..................................................... 4 4.6. Recap: Type Synonyms, newtype ............................................................................. 4 5. 5 Algebraic Data Types ......................................................................................................... 5 5.1. Constructors .............................................................................................................. 5 5.2. Constructors (cont'd) ................................................................................................. 5 5.3. Sum of Types ............................................................................................................ 5 5.4. Product of Types ....................................................................................................... 6 5.5. Product of Types: Records ........................................................................................ 6 5.6. Product of Types: Records ........................................................................................ 6 5.7. Parametric ADTs ...................................................................................................... 7 5.8. Recursive ADTs ....................................................................................................... 7 5.9. Recursive, Parametric ADTs .................................................................................... 7 5.10. Recursive, Parametric ADTs (cont'd) ..................................................................... 8 6. 6 Higher-Order Types ........................................................................................................... 8 6.1. Introducing Higher-Order Types and Kinds ............................................................. 8 6.2. Example .................................................................................................................... 9 7. 7 Type Classes ...................................................................................................................... 9 7.1. Overloading Functions ............................................................................................. 9 7.2. Type Classes ............................................................................................................. 9 7.3. Type Class Instances .............................................................................................. 10 7.4. Class Contexts ........................................................................................................ 10 7.5. Instances Defined Through Overloading ................................................................ 10 7.6. Overlapping Instances ............................................................................................ 11 7.7. Overlapping Instances: Example (Clean) ............................................................... 11 7.8. Ambiguous Overloading ......................................................................................... 11 7.9. Deriving Members of Classes ................................................................................. 12 7.10. Classes Defined Through Other Classes ............................................................... 12 7.11. Deriving Type Class Instances (Haskell) .............................................................. 12 8. 8 Existential Types .............................................................................................................. 13 8.1. Introduction ............................................................................................................ 13 8.2. Examples of Use (Haskell) ..................................................................................... 13 8.3. Examples of Use (Clean) ........................................................................................ 13 9. 9 Uniqueness Typing ........................................................................................................... 14 9.1. Defining Uniqueness .............................................................................................. 14 9.2. Basic Ideas .............................................................................................................. 14 9.3. Writing Files ........................................................................................................... 14 9.4. Attribute Variables ................................................................................................. 15 9.5. Attribute Propagation ............................................................................................. 15 9.6. Restrictions on Propagation .................................................................................... 15 9.7. Employing Coercion Statements ............................................................................ 16 9.8. Employing Coercion Statements (cont'd) ............................................................... 16 9.9. New Types with Uniqueness Attributes ................................................................. 16 iii Created by XMLmind XSL-FO Converter. Advanced Functional Programming 9.10. Standard Attribution for New Types .................................................................... 17 9.11. Combining Uniqueness Typing and Overloading ................................................. 17 9.12. Application: I/O in Clean ...................................................................................... 17 10. 10 Dynamics ..................................................................................................................... 17 10.1. What is Dynamics? ............................................................................................... 17 10.2. What is Dynamics? (cont'd) .................................................................................. 18 10.3. Packing Expressions into a Dynamic .................................................................... 18 10.4. Packing Arguments of Unknown Type ................................................................. 18 10.5. Defeating the Static Type System ......................................................................... 19 10.6. Unpacking a Dynamic Using Pattern Matching ................................................... 19 10.7. Dynamic Pattern Matching for Polymorphic Functions ....................................... 19 10.8. Dynamic Pattern Matching: Summary ................................................................. 20 10.9. Checking and Unifying Type Schemes ................................................................ 20 10.10. Checking and Unifying Type Schemes - Examples ............................................ 20 10.11. Checking and Unifying Unknown Types Using Overloaded Type Variables .... 21 10.12. Type-Safe Communication Using Dynamics ..................................................... 21 10.13. Type-Safe Communication Using Dynamics: Example ..................................... 21 10.14. Architecture of the Implementation .................................................................... 22 11. 11 Generic Programming .................................................................................................. 22 11.1. Motivation ............................................................................................................ 22 11.2. Universal Representation of Types ......................................................................
Load more

Recommended publications
  • Akka Java Documentation Release 2.2.5
    Akka Java Documentation Release 2.2.5 Typesafe Inc February 19, 2015 CONTENTS 1 Introduction 1 1.1 What is Akka?............................................1 1.2 Why Akka?..............................................3 1.3 Getting Started............................................3 1.4 The Obligatory Hello World.....................................7 1.5 Use-case and Deployment Scenarios.................................8 1.6 Examples of use-cases for Akka...................................9 2 General 10 2.1 Terminology, Concepts........................................ 10 2.2 Actor Systems............................................ 12 2.3 What is an Actor?.......................................... 14 2.4 Supervision and Monitoring..................................... 16 2.5 Actor References, Paths and Addresses............................... 19 2.6 Location Transparency........................................ 25 2.7 Akka and the Java Memory Model.................................. 26 2.8 Message Delivery Guarantees.................................... 28 2.9 Configuration............................................. 33 3 Actors 65 3.1 Actors................................................ 65 3.2 Typed Actors............................................. 84 3.3 Fault Tolerance............................................ 88 3.4 Dispatchers.............................................. 103 3.5 Mailboxes.............................................. 106 3.6 Routing................................................ 111 3.7 Building Finite State Machine
    [Show full text]
  • UNIT-I Mathematical Logic Statements and Notations
    UNIT-I Mathematical Logic Statements and notations: A proposition or statement is a declarative sentence that is either true or false (but not both). For instance, the following are propositions: “Paris is in France” (true), “London is in Denmark” (false), “2 < 4” (true), “4 = 7 (false)”. However the following are not propositions: “what is your name?” (this is a question), “do your homework” (this is a command), “this sentence is false” (neither true nor false), “x is an even number” (it depends on what x represents), “Socrates” (it is not even a sentence). The truth or falsehood of a proposition is called its truth value. Connectives: Connectives are used for making compound propositions. The main ones are the following (p and q represent given propositions): Name Represented Meaning Negation ¬p “not p” Conjunction p q “p and q” Disjunction p q “p or q (or both)” Exclusive Or p q “either p or q, but not both” Implication p ⊕ q “if p then q” Biconditional p q “p if and only if q” Truth Tables: Logical identity Logical identity is an operation on one logical value, typically the value of a proposition that produces a value of true if its operand is true and a value of false if its operand is false. The truth table for the logical identity operator is as follows: Logical Identity p p T T F F Logical negation Logical negation is an operation on one logical value, typically the value of a proposition that produces a value of true if its operand is false and a value of false if its operand is true.
    [Show full text]
  • Chapter 1 Logic and Set Theory
    Chapter 1 Logic and Set Theory To criticize mathematics for its abstraction is to miss the point entirely. Abstraction is what makes mathematics work. If you concentrate too closely on too limited an application of a mathematical idea, you rob the mathematician of his most important tools: analogy, generality, and simplicity. – Ian Stewart Does God play dice? The mathematics of chaos In mathematics, a proof is a demonstration that, assuming certain axioms, some statement is necessarily true. That is, a proof is a logical argument, not an empir- ical one. One must demonstrate that a proposition is true in all cases before it is considered a theorem of mathematics. An unproven proposition for which there is some sort of empirical evidence is known as a conjecture. Mathematical logic is the framework upon which rigorous proofs are built. It is the study of the principles and criteria of valid inference and demonstrations. Logicians have analyzed set theory in great details, formulating a collection of axioms that affords a broad enough and strong enough foundation to mathematical reasoning. The standard form of axiomatic set theory is denoted ZFC and it consists of the Zermelo-Fraenkel (ZF) axioms combined with the axiom of choice (C). Each of the axioms included in this theory expresses a property of sets that is widely accepted by mathematicians. It is unfortunately true that careless use of set theory can lead to contradictions. Avoiding such contradictions was one of the original motivations for the axiomatization of set theory. 1 2 CHAPTER 1. LOGIC AND SET THEORY A rigorous analysis of set theory belongs to the foundations of mathematics and mathematical logic.
    [Show full text]
  • Folktale Documentation Release 1.0
    Folktale Documentation Release 1.0 Quildreen Motta Nov 05, 2017 Contents 1 Guides 3 2 Indices and tables 5 3 Other resources 7 3.1 Getting started..............................................7 3.2 Folktale by Example........................................... 10 3.3 API Reference.............................................. 12 3.4 How do I................................................... 63 3.5 Glossary................................................. 63 Python Module Index 65 i ii Folktale Documentation, Release 1.0 Folktale is a suite of libraries for generic functional programming in JavaScript that allows you to write elegant modular applications with fewer bugs, and more reuse. Contents 1 Folktale Documentation, Release 1.0 2 Contents CHAPTER 1 Guides • Getting Started A series of quick tutorials to get you up and running quickly with the Folktale libraries. • API reference A quick reference of Folktale’s libraries, including usage examples and cross-references. 3 Folktale Documentation, Release 1.0 4 Chapter 1. Guides CHAPTER 2 Indices and tables • Global Module Index Quick access to all modules. • General Index All functions, classes, terms, sections. • Search page Search this documentation. 5 Folktale Documentation, Release 1.0 6 Chapter 2. Indices and tables CHAPTER 3 Other resources • Licence information 3.1 Getting started This guide will cover everything you need to start using the Folktale project right away, from giving you a brief overview of the project, to installing it, to creating a simple example. Once you get the hang of things, the Folktale By Example guide should help you understanding the concepts behind the library, and mapping them to real use cases. 3.1.1 So, what’s Folktale anyways? Folktale is a suite of libraries for allowing a particular style of functional programming in JavaScript.
    [Show full text]
  • Theorem Proving in Classical Logic
    MEng Individual Project Imperial College London Department of Computing Theorem Proving in Classical Logic Supervisor: Dr. Steffen van Bakel Author: David Davies Second Marker: Dr. Nicolas Wu June 16, 2021 Abstract It is well known that functional programming and logic are deeply intertwined. This has led to many systems capable of expressing both propositional and first order logic, that also operate as well-typed programs. What currently ties popular theorem provers together is their basis in intuitionistic logic, where one cannot prove the law of the excluded middle, ‘A A’ – that any proposition is either true or false. In classical logic this notion is provable, and the_: corresponding programs turn out to be those with control operators. In this report, we explore and expand upon the research about calculi that correspond with classical logic; and the problems that occur for those relating to first order logic. To see how these calculi behave in practice, we develop and implement functional languages for propositional and first order logic, expressing classical calculi in the setting of a theorem prover, much like Agda and Coq. In the first order language, users are able to define inductive data and record types; importantly, they are able to write computable programs that have a correspondence with classical propositions. Acknowledgements I would like to thank Steffen van Bakel, my supervisor, for his support throughout this project and helping find a topic of study based on my interests, for which I am incredibly grateful. His insight and advice have been invaluable. I would also like to thank my second marker, Nicolas Wu, for introducing me to the world of dependent types, and suggesting useful resources that have aided me greatly during this report.
    [Show full text]
  • Learning Dependency-Based Compositional Semantics
    Learning Dependency-Based Compositional Semantics Percy Liang∗ University of California, Berkeley Michael I. Jordan∗∗ University of California, Berkeley Dan Klein† University of California, Berkeley Suppose we want to build a system that answers a natural language question by representing its semantics as a logical form and computing the answer given a structured database of facts. The core part of such a system is the semantic parser that maps questions to logical forms. Semantic parsers are typically trained from examples of questions annotated with their target logical forms, but this type of annotation is expensive. Our goal is to instead learn a semantic parser from question–answer pairs, where the logical form is modeled as a latent variable. We develop a new semantic formalism, dependency-based compositional semantics (DCS) and define a log-linear distribution over DCS logical forms. The model parameters are estimated using a simple procedure that alternates between beam search and numerical optimization. On two standard semantic parsing benchmarks, we show that our system obtains comparable accuracies to even state-of-the-art systems that do require annotated logical forms. 1. Introduction One of the major challenges in natural language processing (NLP) is building systems that both handle complex linguistic phenomena and require minimal human effort. The difficulty of achieving both criteria is particularly evident in training semantic parsers, where annotating linguistic expressions with their associated logical forms is expensive but until recently, seemingly unavoidable. Advances in learning latent-variable models, however, have made it possible to progressively reduce the amount of supervision ∗ Computer Science Division, University of California, Berkeley, CA 94720, USA.
    [Show full text]
  • Type-Driven Development of Concurrent Communicating Systems
    Edwin Brady TYPE-DRIVEN DEVELOPMENT OF CONCURRENT COMMUNICATING SYSTEMS Abstract Modern software systems rely on communication, for example mobile appli- cations communicating with a central server, distributed systems coordinat- ing a telecommunications network, or concurrent systems handling events and processes in a desktop application. However, reasoning about concurrent pro- grams is hard, since we must reason about each process and the order in which communication might happen between processes. In this paper, I describe a type-driven approach to implementing communicating concurrent programs, using the dependently typed programming language Idris. I show how the type system can be used to describe resource access protocols (such as controlling access to a file handle) and verify that programs correctly follow those pro- tools. Finally, I show how to use the type system to reason about the order of communication between concurrent processes, ensuring that each end of a communication channel follows a defined protocol. Keywords Dependent Types, Domain Specific Languages, Verification, Concurrency 2015/02/24; 00:02 str. 1/21 1. Introduction Implementing communicating concurrent systems is hard, and reasoning about them even more so. Nevertheless, the majority of modern software systems rely to some extent on communication, whether over a network to a server such as a web or mail server, between peers in a networked distributed system, or between processes in a concurrent desktop system. Reasoning about concurrent systems is particularly difficult; the order of processing is not known in advance, since processes are running independently. In this paper, I describe a type-driven approach to reasoning about message passing concurrent programs, using a technique similar to Honda's Session Types [14].
    [Show full text]
  • Parsing with First-Class Derivatives
    Parsing with First-Class Derivatives Jonathan Immanuel Brachthauser¨ Tillmann Rendel Klaus Ostermann rtifact A Comple * t * te n * A * te is W E s A e n C l l L o D C S University of Tubingen,¨ Germany o * * c P u e m s E u O e e n v R t e O o d t a y * s E a * fbrachthaeuser, rendel, [email protected] l u d a e t Abstract often reducing the modularity of their parser because these ad- Brzozowski derivatives, well known in the context of reg- hoc additions are cross-cutting with respect to the otherwise ular expressions, have recently been rediscovered to give a context-free syntactic structure of the language. simplified explanation to parsers of context-free languages. Parser combinators [10, 10, 15, 21, 22] are a parsing We add derivatives as a novel first-class feature to a standard approach that is well-suited for such ad-hoc additions. With parser combinator language. First-class derivatives enable an parser combinators, a parser is described as a first-class inversion of the control flow, allowing to implement modular entity in some host language, and parsers for smaller subsets parsers for languages that previously required separate pre- of a language are combined into parsers of larger subsets processing steps or cross-cutting modifications of the parsers. using built-in or user-defined combinators such as sequence, We show that our framework offers new opportunities for alternative, or iteration. The fact that parsers are first-class reuse and supports a modular definition of interesting use entities at runtime allows an elegant way of structuring cases of layout-sensitive parsing.
    [Show full text]
  • Logical Vs. Natural Language Conjunctions in Czech: a Comparative Study
    ITAT 2016 Proceedings, CEUR Workshop Proceedings Vol. 1649, pp. 68–73 http://ceur-ws.org/Vol-1649, Series ISSN 1613-0073, c 2016 K. Prikrylová,ˇ V. Kubon,ˇ K. Veselovská Logical vs. Natural Language Conjunctions in Czech: A Comparative Study Katrin Prikrylová,ˇ Vladislav Kubon,ˇ and Katerinaˇ Veselovská Charles University in Prague, Faculty of Mathematics and Physics Czech Republic {prikrylova,vk,veselovska}@ufal.mff.cuni.cz Abstract: This paper studies the relationship between con- ceptions and irregularities which do not abide the rules as junctions in a natural language (Czech) and their logical strictly as it is the case in logic. counterparts. It shows that the process of transformation Primarily due to this difference, the transformation of of a natural language expression into its logical representa- natural language sentences into their logical representation tion is not straightforward. The paper concentrates on the constitutes a complex issue. As we are going to show in most frequently used logical conjunctions, and , and it the subsequent sections, there are no simple rules which analyzes the natural language phenomena which∧ influence∨ would allow automation of the process – the majority of their transformation into logical conjunction and disjunc- problematic cases requires an individual approach. tion. The phenomena discussed in the paper are temporal In the following text we are going to restrict our ob- sequence, expressions describing mutual relationship and servations to the two most frequently used conjunctions, the consequences of using plural. namely a (and) and nebo (or). 1 Introduction and motivation 2 Sentences containing the conjunction a (and) The endeavor to express natural language sentences in the form of logical expressions is probably as old as logic it- The initial assumption about complex sentences contain- self.
    [Show full text]
  • Presupposition Projection and Entailment Relations
    Presupposition Projection and Entailment Relations Amaia Garcia Odon i Acknowledgements I would like to thank the members of my thesis committee, Prof. Dr. Rob van der Sandt, Dr. Henk Zeevat, Dr. Isidora Stojanovic, Dr. Cornelia Ebert and Dr. Enric Vallduví for having accepted to be on my thesis committee. I am extremely grateful to my adviser, Louise McNally, and to Rob van der Sandt. Without their invaluable help, I would not have written this dissertation. Louise has been a wonderful adviser, who has always provided me with excellent guid- ance and continuous encouragement. Rob has been a mentor who has generously spent much time with me, teaching me Logic, discussing my work, and helping me clear up my thoughts. Very special thanks to Henk Zeevat for having shared his insights with me and for having convinced me that it was possible to finish on time. Thanks to Bart Geurts, Noor van Leusen, Sammie Tarenskeen, Bob van Tiel, Natalia Zevakhina and Corien Bary in Nijmegen; to Paul Dekker, Jeroen Groe- nendijk, Frank Veltman, Floris Roelofsen, Morgan Mameni, Raquel Fernández and Margot Colinet in Amsterdam; to Fernando García Murga, Agustín Vicente, Myriam Uribe-Etxebarria, Javier Ormazabal, Vidal Valmala, Gorka Elordieta, Urtzi Etxeberria and Javi Fernández in Vitoria-Gasteiz, to David Beaver and Mari- bel Romero. Also thanks to the people I met at the ESSLLIs of Bordeaux, Copen- hagen and Ljubljana, especially to Nick Asher, Craige Roberts, Judith Tonhauser, Fenghui Zhang, Mingya Liu, Alexandra Spalek, Cornelia Ebert and Elena Pa- ducheva. I gratefully acknowledge the financial help provided by the Basque Government – Departamento de Educación, Universidades e Investigación (BFI07.96) and Fun- dación ICREA (via an ICREA Academia award to Louise McNally).
    [Show full text]
  • Warp: a Haskell Web Server
    The Functional Web Warp: A Haskell Web Server Michael Snoyman • Suite Solutions oughly two years ago, I began work on about this runtime is its lightweight threads. As the Yesod Web framework. I originally a result of this feature, Warp simply spawns a R intended FastCGI for my deployment strat- new thread for each incoming connection, bliss- egy, but I also created a simple HTTP server for fully unaware of the gymnastics the runtime is local testing, creatively named SimpleServer. performing under the surface. Because Yesod targets the Web Application Part of this abstraction involves converting Interface (WAI), a standard interface between synchronous Haskell I/O calls into asynchro- Haskell Web servers and Web applications, it nous system calls. Once again, Warp reaps the was easy to switch back ends for testing and benefits by calling simple functions like recv production. and send, while GHC does the hard work. It didn’t take long before I started getting Up through GHC 6.12, this runtime sys- feature requests for SimpleServer: slowly but tem was based on the select system call. This surely, features such as chunked transfer encod- worked well enough for many tasks but didn’t ing and sendfile-based file serving made their scale for Web servers. One big feature of the way in. The tipping point was when Matt Brown GHC 7 release was a new event manager, written of Soft Mechanics made some minor tweaks by Google’s Johan Tibell and Serpentine’s Bryan to SimpleServer and found that it was already O’Sullivan. This new runtime uses different sys- the fastest Web server in Haskell (see Figure 1).
    [Show full text]
  • Interleaving Data and Effects"
    Archived version from NCDOCKS Institutional Repository http://libres.uncg.edu/ir/asu/ Interleaving data and effects By: Robert Atkey and Patricia Johann Abstract: The study of programming with and reasoning about inductive datatypes such as lists and trees has benefited from the simple categorical principle of initial algebras. In initial algebra semantics, each inductive datatype is represented by an initial f-algebra for an appropriate functor f. The initial algebra principle then supports the straightforward derivation of definitional principles and proof principles for these datatypes. This technique has been expanded to a whole methodology of structured functional programming, often called origami programming.In this article we show how to extend initial algebra semantics from pure inductive datatypes to inductive datatypes interleaved with computational effects. Inductive datatypes interleaved with effects arise naturally in many computational settings. For example, incrementally reading characters from a file generates a list of characters interleaved with input/output actions, and lazily constructed infinite values can be represented by pure data interleaved with the possibility of non-terminating computation. Straightforward application of initial algebra techniques to effectful datatypes leads either to unsound conclusions if we ignore the possibility of effects, or to unnecessarily complicated reasoning because the pure and effectful concerns must be considered simultaneously. We show how pure and effectful concerns can be separated using the abstraction of initial f-and-m-algebras, where the functor f describes the pure part of a datatype and the monad m describes the interleaved effects. Because initial f-and-m-algebras are the analogue for the effectful setting of initial f- algebras, they support the extension of the standard definitional and proof principles to the effectful setting.
    [Show full text]