Haskell: Flow of Control

Total Page:16

File Type:pdf, Size:1020Kb

Haskell: Flow of Control Haskell: Flow of Control CS F331 Programming Languages CSCE A331 Programming Language Concepts Lecture Slides Wednesday, February 27, 2019 Glenn G. Chappell Department of Computer Science University of Alaska Fairbanks [email protected] © 2017–2019 Glenn G. Chappell Review PL Category: Functional PLs [1/2] Imperative programming: code tells a computer what to do. Declarative programming: code tells a computer what is true. Functional programming (FP) is a declarative programming style that generally has the following characteristics. § Computation is considered primarily in terms of the evaluation of functions—as opposed to execution of tasks. § Functions are a primary concern. Rather than mere repositories for code, functions are values to be constructed and manipulated. § Side effects* are avoided. A function’s only job is to return a value. *A function has a side effect when it makes a change, other than returning a value, that is visible outside the function. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 2 Review PL Category: Functional PLs [2/2] A functional programming language is a PL designed to support FP well. A pure functional PL goes further, and does not support mutable data at all. There are no side effects in a pure functional PL. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 3 Review Haskell: Functions — Basic Syntax [1/2] Identifiers begin with a letter or underscore, and contain only letters, underscores, digits, and single quotes ('). There are two kinds of identifiers. § Normal identifiers begin with a lower-case letter or underscore. These name variables and functions. § Special identifiers begin with an UPPER-CASE letter. These name modules, types, and constructors. (This is not merely a convention!) myVariable -- Normal _my_Function'_33 -- Normal MyModule -- Special For code from this topic, see func.hs. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 4 Review Haskell: Functions — Basic Syntax [2/2] To define a function, write what looks like a call to the function, an equals sign, and then an expression. addem a b = a+b Parentheses may be used around individual arguments, due to precedence & associativity issues. addem 18 (5*7) Use where to introduce a block of local definitions. lenSquared x y = sq x + sq y where sq z = z*z 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 5 Review Haskell: Functions — Defining Operators We can define new infix binary operators. We can optionally set an operator’s precedence and associativity. a +$+ b = 2*a + b infixl 6 +$+ -- Left-associative, precedence level 6 Use a regular function as an infix binary operator by surrounding its name with backquotes (`). 2 `addem` 3 Use an infix binary operator as a regular function by surrounding its name with parentheses. (+$+) 5 7 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 6 Review Haskell: Functions — Currying Currying: simulating a multiple-argument function using a single- argument function that returns a function. Multiple-argument functions in Haskell are curried. addem x y = x+y add2 = addem 2 > add2 3 5 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 7 Review Haskell: Functions — Higher-Order Functions, Lambda Functions Higher-order function: function that acts on functions. rev f a b = f b a sub x y = x-y rsub = rev sub > rsub 5 8 -3 Lambda function: function with no name. > (\ x -> x*x) 5 25 > map (\ x -> x*x) [2, 3, 8] [4,9,64] 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 8 Review Haskell: Lists — Lists & Tuples List: holds an arbitrary number of items, all of the same type. [1, 4, 2] [] ['h','e','l','l','o'] "hello" -- Same as previous line [[1,2],[],[3],[4,5,6]] [1,3..] -- Infinite list: ALL positive odd integers Tuple: holds a fixed number of items, possibly of different types. (True, "abc", 34.6, [3,8]) For code from this topic, see list.hs. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 9 Review Haskell: Lists — List Primitives Three list primitives. 1. Construct an empty list. [] 2. Cons: construct a list given its first item and a list of other items. Uses the infix colon (:) operator. [5, 2, 1, 8] 5:[2, 1, 8] -- Same as above 5:2:1:8:[] -- Also same; ":" is right-associative 3. Pattern matching for lists. x:xs -- Pattern that matches a nonempty list 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 10 Review Haskell: Lists — Other List Syntax List comprehension: > [ x*y | x <- [3, 2, 1], y <- [10, 11, 12] ] [30,33,36,20,22,24,10,11,12] > [ a | a <- [6,5,4,3,2,1], a > 3 ] [6,5,4] 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 11 Review Haskell: Lists — Lists & Recursion [1/2] A function that takes a list will often be recursive. The base case handles the empty list. The recursive case handles a nonempty list. This might do a computation involving the head (b above) and make a recursive call on the tail (bs above). TO DO § Write a function myMap that replicates the Prelude function map. § Look at the Prelude function filter. § Replicate filter as myFilter. A predicate is a function that returns a Boolean value. A useful construction: if COND then EXPR1 else EXPR2. § COND is an expression of type Bool. If it is True, then EXPR1 is returned. If it is False, then EXPR2 is returned. § Expressions EXPR1 and EXPR2 must have the same type. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 12 Review Haskell: Lists — Lists & Recursion [2/2] Sometimes other kinds of recursion are used. TO DO § Write a function lookInd that does item lookup by index (zero- based) in a list. Useful § The pattern “_” means unused parameter. § Function error takes a String and returns any type. When it executes, it crashes, printing an error message, which should include the given string. § undefined is like error, but it takes no arguments. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 13 Haskell: Flow of Control Introduction Flow of control refers to the ways a PL determines what code is executed. For example, flow of control in Lua includes: § Selection (if … elseif … else). § Iteration (while, for). § Function calls. § Coroutines. § Threads. § Exceptions. Haskell has very different flow-of-control facilities from most PLs that are oriented toward imperative programming. Key Idea. Things that are done with traditional flow-of-control constructs in other programming languages are often done differently in Haskell. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 14 Haskell: Flow of Control Pattern Matching, Recursion, Lazy Evaluation [1/5] We have seen that Haskell has a useful pattern matching facility, which allows us to choose one of a number of function definitions. The rule is that the first definition with a matching pattern is the one used. isEmpty [] = True isEmpty (x:xs) = False -- fibo the SLOW way fibo 0 = 0 fibo 1 = 1 fibo n = fibo (n-2) + fibo (n-1) In many of the places we would use an if … else construction in other PLs, we use pattern matching in Haskell. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 15 Haskell: Flow of Control Pattern Matching, Recursion, Lazy Evaluation [2/5] Haskell also makes heavy use of recursion. lookInd 0 (x:xs) = x lookInd n (x:xs) = lookInd (n-1) xs lookInd _ [] = error "lookInd: index out of range" In places where we would use a loop in an imperative PL, we use recursion in Haskell. Recursion can be less costly in Haskell than in PLs like C++, because of Haskell’s required tail-call optimization (TCO). TCO means that a tail call does not use additional stack space. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 16 Haskell: Flow of Control Pattern Matching, Recursion, Lazy Evaluation [3/5] By default, Haskell does lazy evaluation. This allows for infinite lists. We have said that we can generate these even without the “..” syntax. But how? Here is an idea. -- listFrom n -- Returns the infinite list [n, n+1, n+2, ...]. listFrom n = n:listFrom (n+1) Is the above code acceptable? It does recursion with no base case. But this is not a problem, thanks to lazy evaluation. A recursive call is only made if further list items are needed. Using only a finite number of items guarantees that the recursion terminates. This is called corecursion: § A stream of values is generated recursively, as needed. § The recursion terminates when no more values are requested. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 17 Haskell: Flow of Control Pattern Matching, Recursion, Lazy Evaluation [4/5] Something else we can do: write our own if … else, as a function. -- myIf condition tVal fVal -- Returns tVal if condition is True, fVal otherwise. myIf True tVal _ = tVal myIf False _ fVal = fVal Thanks to lazy evaluation, no more than one of tVal, fVal is ever evaluated. Here is the slow Fibonacci algorithm using myIf. fibo n = myIf (n <= 1) n (fibo (n-2) + fibo (n-1)) 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 18 Haskell: Flow of Control Pattern Matching, Recursion, Lazy Evaluation [5/5] And here is myFilter, reimplemented using myIf. myFilter p [] = [] myFilter p (x:xs) = myIf (p x) (x:rest) rest where rest = myFilter p xs It turns out that the combination of pattern matching, recursion, and lazy evaluation, together with function calls, are all we need. We can build any flow-of-control construct out of these. However, Haskell has other flow-of-control facilities, for convenience. Next we look at a few of these. 27 Feb 2019 CS F331 / CSCE A331 Spring 2019 19 Haskell: Flow of Control Selection — Introduction Selection allows us to choose one of multiple options to execute.
Recommended publications
  • GHC Reading Guide
    GHC Reading Guide - Exploring entrances and mental models to the source code - Takenobu T. Rev. 0.01.1 WIP NOTE: - This is not an official document by the ghc development team. - Please refer to the official documents in detail. - Don't forget “semantics”. It's very important. - This is written for ghc 9.0. Contents Introduction 1. Compiler - Compilation pipeline - Each pipeline stages - Intermediate language syntax - Call graph 2. Runtime system 3. Core libraries Appendix References Introduction Introduction Official resources are here GHC source repository : The GHC Commentary (for developers) : https://gitlab.haskell.org/ghc/ghc https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary GHC Documentation (for users) : * master HEAD https://ghc.gitlab.haskell.org/ghc/doc/ * latest major release https://downloads.haskell.org/~ghc/latest/docs/html/ * version specified https://downloads.haskell.org/~ghc/9.0.1/docs/html/ The User's Guide Core Libraries GHC API Introduction The GHC = Compiler + Runtime System (RTS) + Core Libraries Haskell source (.hs) GHC compiler RuntimeSystem Core Libraries object (.o) (libHsRts.o) (GHC.Base, ...) Linker Executable binary including the RTS (* static link case) Introduction Each division is located in the GHC source tree GHC source repository : https://gitlab.haskell.org/ghc/ghc compiler/ ... compiler sources rts/ ... runtime system sources libraries/ ... core library sources ghc/ ... compiler main includes/ ... include files testsuite/ ... test suites nofib/ ... performance tests mk/ ... build system hadrian/ ... hadrian build system docs/ ... documents : : 1. Compiler 1. Compiler Compilation pipeline 1. compiler The GHC compiler Haskell language GHC compiler Assembly language (native or llvm) 1. compiler GHC compiler comprises pipeline stages GHC compiler Haskell language Parser Renamer Type checker Desugarer Core to Core Core to STG STG to Cmm Assembly language Cmm to Asm (native or llvm) 1.
    [Show full text]
  • Haskell-Like S-Expression-Based Language Designed for an IDE
    Department of Computing Imperial College London MEng Individual Project Haskell-Like S-Expression-Based Language Designed for an IDE Author: Supervisor: Michal Srb Prof. Susan Eisenbach June 2015 Abstract The state of the programmers’ toolbox is abysmal. Although substantial effort is put into the development of powerful integrated development environments (IDEs), their features often lack capabilities desired by programmers and target primarily classical object oriented languages. This report documents the results of designing a modern programming language with its IDE in mind. We introduce a new statically typed functional language with strong metaprogramming capabilities, targeting JavaScript, the most popular runtime of today; and its accompanying browser-based IDE. We demonstrate the advantages resulting from designing both the language and its IDE at the same time and evaluate the resulting environment by employing it to solve a variety of nontrivial programming tasks. Our results demonstrate that programmers can greatly benefit from the combined application of modern approaches to programming tools. I would like to express my sincere gratitude to Susan, Sophia and Tristan for their invaluable feedback on this project, my family, my parents Michal and Jana and my grandmothers Hana and Jaroslava for supporting me throughout my studies, and to all my friends, especially to Harry whom I met at the interview day and seem to not be able to get rid of ever since. ii Contents Abstract i Contents iii 1 Introduction 1 1.1 Objectives ........................................ 2 1.2 Challenges ........................................ 3 1.3 Contributions ...................................... 4 2 State of the Art 6 2.1 Languages ........................................ 6 2.1.1 Haskell ....................................
    [Show full text]
  • A Formal Methodology for Deriving Purely Functional Programs from Z Specifications Via the Intermediate Specification Language Funz
    Louisiana State University LSU Digital Commons LSU Historical Dissertations and Theses Graduate School 1995 A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ. Linda Bostwick Sherrell Louisiana State University and Agricultural & Mechanical College Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_disstheses Recommended Citation Sherrell, Linda Bostwick, "A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ." (1995). LSU Historical Dissertations and Theses. 5981. https://digitalcommons.lsu.edu/gradschool_disstheses/5981 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Historical Dissertations and Theses by an authorized administrator of LSU Digital Commons. For more information, please contact [email protected]. INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. H ie quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandardm argins, and improper alignment can adversely affect reproduction. In the unlikely, event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps.
    [Show full text]
  • The Logic of Demand in Haskell
    Under consideration for publication in J. Functional Programming 1 The Logic of Demand in Haskell WILLIAM L. HARRISON Department of Computer Science University of Missouri Columbia, Missouri RICHARD B. KIEBURTZ Pacific Software Research Center OGI School of Science & Engineering Oregon Health & Science University Abstract Haskell is a functional programming language whose evaluation is lazy by default. However, Haskell also provides pattern matching facilities which add a modicum of eagerness to its otherwise lazy default evaluation. This mixed or “non-strict” semantics can be quite difficult to reason with. This paper introduces a programming logic, P-logic, which neatly formalizes the mixed evaluation in Haskell pattern-matching as a logic, thereby simplifying the task of specifying and verifying Haskell programs. In P-logic, aspects of demand are reflected or represented within both the predicate language and its model theory, allowing for expressive and comprehensible program verification. 1 Introduction Although Haskell is known as a lazy functional language because of its default eval- uation strategy, it contains a number of language constructs that force exceptions to that strategy. Among these features are pattern-matching, data type strictness annotations and the seq primitive. The semantics of pattern-matching are further enriched by irrefutable pattern annotations, which may be embedded within pat- terns. The interaction between Haskell’s default lazy evaluation and its pattern- matching is surprisingly complicated. Although it offers the programmer a facility for fine control of demand (Harrison et al., 2002), it is perhaps the aspect of the Haskell language least well understood by its community of users. In this paper, we characterize the control of demand first in a denotational semantics and then in a verification logic called “P-logic”.
    [Show full text]
  • Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers
    Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers Jeremy Singer and Blair Archibald School of Computing Science University of Glasgow UK [email protected] [email protected] What kinds of mistakes are made by novice Haskell developers, as they learn about functional pro- gramming? Is it possible to analyze these errors in order to improve the pedagogy of Haskell? In 2016, we delivered a massive open online course which featured an interactive code evaluation en- vironment. We captured and analyzed 161K interactions from learners. We report typical novice developer behavior; for instance, the mean time spent on an interactive tutorial is around eight min- utes. Although our environment was restricted, we gain some understanding of Haskell novice er- rors. Parenthesis mismatches, lexical scoping errors and do block misunderstandings are common. Finally, we make recommendations about how such beginner code evaluation environments might be enhanced. 1 Introduction The Haskell programming language [14] has acquired a reputation for being difficult to learn. In his presentation on the origins of Haskell [23] Peyton Jones notes that, according to various programming language popularity metrics, Haskell is much more frequently discussed than it is used for software implementation. The xkcd comic series features a sarcastic strip on Haskell’s side-effect free property [21]. Haskell code is free from side-effects ‘because no-one will ever run it.’ In 2016, we ran the first instance of a massive open online course (MOOC) at Glasgow, providing an introduction to functional programming in Haskell. We received many items of learner feedback that indicated difficulty in learning Haskell.
    [Show full text]
  • Haskell As a Higher Order Structural Hardware Description Language
    Haskell as a higher order structural hardware description language Master's thesis by Matthijs Kooijman December 9, 2009 Committee: Dr. Ir. Jan Kuper Ir. Marco Gerards Ir. Bert Molenkamp Dr. Ir. Sabih Gerez Computer Architecture for Embedded Systems Faculty of EEMCS University of Twente Abstract Functional hardware description languages have been around for a while, but never saw adoption on a large scale. Even though advanced features like higher order functions and polymorphism could enable very natural parametrization of hardware descriptions, the conventional hardware description languages VHDL and Verilog are still most widely used. Cλash is a new functional hardware description language using Haskell's syntax and semantics. It allows structurally describing synchronous hardware, using normal Haskell syntax combined with a selection of built-in functions for operations like addition or list operations. More complex constructions like higher order functions and polymorphism are fully supported. Cλash supports stateful descriptions through explicit descriptions of a function's state. Every function accepts an argument containing its current state and returns its updated state as a part of its result. This means every function is called exactly once for each cycle, limiting Cλash to synchronous systems with a single clock domain. A prototype compiler for Cλash has been implemented that can generate an equivalent VHDL description (using mostly structural VHDL). The prototype uses the front-end (parser, type-checker, desugarer) ofthe existing GHC Haskell compiler. This front-end generates a Core version of the description, which is a very small typed functional language. A normalizing system of transformations brings this Core version into a normal form that has any complex parts (higher order functions, polymorphism, complex nested structures) removed.
    [Show full text]
  • A Proxima-Based Haskell IDE
    Thesis for the degree of Master of Science A Proxima-based Haskell IDE Gerbo Engels October 2008 INF/SCR-07-93 Supervisor: Center for Software Technology prof. dr. S. Doaitse Swierstra Dept. of Information and Computing Sciences Universiteit Utrecht Daily supervisor: Utrecht, The Netherlands dr. Martijn M. Schrage Abstract Proxima is a generic presentation-oriented editor for structured documents, in which a graphical presentation of the document can be edited directly (WYSIWYG editing), resulting in changes in the underlying structure of the document. Proxima understands the document structure and it supports direct edit operations on the document structure as well. A Proxima instantiation uses a parser to get the document structure; modern compilers have parsers as well, which may be accessible through an API. Using the parser of an external compiler as the Proxima parser saves one from writing a new parser. Furthermore, the parse tree of a com- piler can contain extra information that is useful to display in an editor, such as type information of a Haskell compiler in a Haskell source code editor. This thesis aims to use the parser of an external compiler as the Proxima parser. We identify and solve problems that arise when using the parser of an external compiler as the Proxima parser, and two Haskell editors are developed as Proxima instantiations that use the parser of GHC or EHC respectively. i ii Contents 1 Introduction 1 1.1 Thesis Overview.........................................2 I The State of the World3 2 Existing Haskell Editors and IDE’s5 2.1 Visual Haskell...........................................6 2.2 Eclipse Plug-in...........................................7 2.3 Haskell Editors Written in Haskell...............................8 2.4 Other Editors or Tools.....................................
    [Show full text]
  • Haskell High Performance Programming Table of Contents
    Haskell High Performance Programming Table of Contents Haskell High Performance Programming Credits About the Author About the Reviewer www.PacktPub.com eBooks, discount offers, and more Why subscribe? Preface What this book covers What you need for this book Who this book is for Conventions Reader feedback Customer support Downloading the example code Downloading the color images of this book Errata Piracy Questions 1. Identifying Bottlenecks Meeting lazy evaluation Writing sum correctly Weak head normal form Folding correctly Memoization and CAFs Constant applicative form Recursion and accumulators The worker/wrapper idiom Guarded recursion Accumulator parameters Inspecting time and space usage Increasing sharing and minimizing allocation Compiler code optimizations Inlining and stream fusion Polymorphism performance Partial functions Summary 2. Choosing the Correct Data Structures Annotating strictness and unpacking datatype fields Unbox with UNPACK Using anonymous tuples Performance of GADTs and branching Handling numerical data Handling binary and textual data Representing bit arrays Handling bytes and blobs of bytes Working with characters and strings Using the text library Builders for iterative construction Builders for strings Handling sequential data Using difference lists Difference list performance Difference list with the Writer monad Using zippers Accessing both ends fast with Seq Handling tabular data Using the vector package Handling sparse data Using the containers package Using the unordered-containers package Ephemeral
    [Show full text]
  • Trace-Based Just-In-Time Compilation for Lazy Functional Programming Languages
    Trace-based Just-in-time Compilation for Lazy Functional Programming Languages Thomas Schilling School of Computing University of Kent at Canterbury A thesis submitted for the degree of Doctor of Philosophy April 2013 i Abstract This thesis investigates the viability of trace-based just-in-time (JIT) compilation for optimising programs written in the lazy functional programming language Haskell. A trace-based JIT compiler optimises only execution paths through the program, which is in contrast to method-based compilers that optimise complete functions at a time. The potential advantages of this approach are shorter compilation times and more natural interprocedural optimisation. Trace-based JIT compilers have previously been used successfully to optimise programs written in dynamically typed languages such as JavaScript, Python, or Lua, but also statically typed languages like Java or the Common Language Runtime (CLR). Lazy evalu- ation poses implementation challenges similar to those of dynamic languages, so trace-based JIT compilation promises to be a viable ap- proach. In this thesis we focus on program performance, but having a JIT compiler available can simplify the implementation of features like runtime inspection and mobile code. We implemented Lambdachine, a trace-based JIT compiler which im- plements most of the pure subset of Haskell. We evaluate Lamb- dachine's performance using a set of micro-benchmarks and a set of larger benchmarks from the \spectral" category of the Nofib bench- mark suite. Lambdachine's performance (excluding garbage collection overheads) is generally about 10 to 20 percent slower than GHC on statically optimised code. We identify the two main causes for this slow-down: trace selection and impeded heap allocation optimisations due to unnecessary thunk updates.
    [Show full text]
  • Introduction to Haskell
    Advanced Topics in Programming Languages Lecture 2 - Introduction to Haskell Ori Bar El Maxim Finkel 01/11/17 1 History Haskell is a lazy, committee designed, pure functional programming language that started development in the late 1980’s. Haskell derives its name from Haskell Curry, a mathematician and logician. The goals of the Haskell language were formally defined by its designers, and they stated that Haskell should: 1. Be suitable for teaching, research, and applications, including building 2. Be completely described via the publication of a formal syntax and se- mantics. 3. Be freely available. 4. Be usable as a basis for further language research. 5. Be based on ideas that enjoy a wide consensus. 6. Reduce unnecessary diversity in functional programming languages. Development of the language began shortly after the 1988 meeting, but it was not until April 1, 1990 that the first working version of Haskell, Haskell 1.0, was released. From 1990 to 1999 many incremental versions of Haskell were released and in 1999 the Haskell Committee decided that a formalized and stable version of the language needed to be released. They decided to call this standard version of the language Haskell 98. The reasoning behind creating a Haskell standard was so the language could be used in teaching environments and books could be written about it. Haskell 98 did not fully stabilize until 2002. Haskell recently released a new standardized version called Haskell 2010. This update includes all the changes in the language since 2002 repackaged with up-to-date documentation in the newest version of the Haskell Report.
    [Show full text]
  • Csci 450: Org. of Programming Languages Basic Haskell Functional Programming
    CSci 450: Org. of Programming Languages Basic Haskell Functional Programming H. Conrad Cunningham 26 October 2017 Contents 2 Basic Haskell Functional Programming 2 2.1 Chapter Introduction . 2 2.2 Defining Our First Haskell Functions . 2 2.2.1 Factorial function specification . 2 2.2.2 Factorial function using if-then-else: fact1 . 3 2.2.3 Factorial function using guards: fact2 ........... 5 2.2.4 Factorial function using pattern matching: fact3 and fact4 6 2.2.5 Factorial function using a built-in library function: fact5 7 2.3 Using the Glasgow Haskell Compiler (GHC) . 7 2.4 Surveying the Basic Types . 10 2.4.1 Integers: Int and Integer . 10 2.4.2 Floating point numbers: Float and Double . 10 2.4.3 Booleans: Bool ........................ 11 2.4.4 Characters: Char ....................... 11 2.4.5 Functions: t1 -> t2 ..................... 11 2.4.6 Tuples: (t1,t2,...,tn) . 12 2.4.7 Lists: [t] ........................... 13 2.4.8 Strings: String ........................ 13 2.5 Using Top-Down Stepwise Refinement . 14 2.5.1 Developing a square root package . 14 2.5.2 Making the package a Haskell module . 16 2.5.3 Top-down stepwise refinement . 16 2.6 Using Data Abstraction . 17 2.6.1 Rational number arithmetic . 17 2.6.2 Rational number data representation . 19 2.6.3 Modularization . 21 2.6.4 Alternative rational number data representation . 22 2.7 Modular Design and Programming . 25 2.7.1 Information-hiding modules . 25 2.7.2 Interfaces . 26 1 2.7.3 Haskell information-hiding modules . 26 2.7.4 Invariants .
    [Show full text]
  • Ready, Set, Verify! Applying Hs-To-Coq to Real-World Haskell Code
    Ready, Set, Verify! Applying hs-to-coq to real-world Haskell code JOACHIM BREITNER, University of Pennsylvania, USA ANTAL SPECTOR-ZABUSKY, University of Pennsylvania, USA YAO LI, University of Pennsylvania, USA CHRISTINE RIZKALLAH, University of New South Wales, Australia JOHN WIEGLEY, BAE Systems, USA STEPHANIE WEIRICH, University of Pennsylvania, USA Good tools can bring mechanical verification to programs written in mainstream functional languages. Weuse hs-to-coq to translate significant portions of Haskell’s containers library into Coq, and verify it against specifications that we derive from a variety of sources including type class laws, the library’s testsuite,and interfaces from Coq’s standard library. Our work shows that it is feasible to verify mature, widely-used, highly optimized, and unmodified Haskell code. We also learn more about the theory of weight-balanced trees, extend hs-to-coq to handle partiality, and – since we found no bugs – attest to the superb quality of well-tested functional code. CCS Concepts: • Software and its engineering → Software verification; Additional Key Words and Phrases: Coq, Haskell, verification 1 INTRODUCTION What would it take to tempt functional programmers to verify their code? Certainly, better tools would help. We see that functional programmers who use dependently- typed languages or proof assistants, such as Coq [The Coq development team 2016], Agda [Bove et al. 2009], Idris [Brady 2017], and Isabelle [Nipkow et al. 2002], do verify their code, since their tools allow it. However, adopting these platforms means rewriting everything from scratch. What about the verification of existing code, such as libraries written in mature languages like Haskell? Haskell programmers can reach for LiquidHaskell [Vazou et al.
    [Show full text]