DOCSLIB.ORG

Syntactic Analysis and Type Evaluation in Haskell

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Syntactic Analysis and Type Evaluation in Haskell MASARYK UNIVERSITY }w¡¢£¤¥¦§¨ FACULTY OF I !"#$%&'()+,-./012345<yA|NFORMATICS Syntactic analysis and type evaluation in Haskell BACHELOR’S THESIS Pavel Dvoˇrák Brno, Spring 2009 Declaration I hereby declare that this thesis is my original work and that, to the best of my knowledge and belief, it contains no material previously published or written by another author except where the citation has been made in the text. ............................................................ signature Adviser: RNDr. Václav Brožek 2 Acknowledgements I am grateful to my adviser Vašek Brožek for his time, great patience, and excel- lent advices, to Libor Škarvada for his worthwhile lectures, to Marek Kružliak for the beautiful Hasky logo, to Miran Lipovaˇca for his cool Haskell tutorial, ∗ to Honza Bartoš, Jirka Hýsek, Tomáš Janoušek, Martin Milata, Peter Molnár, Štˇepán Nˇemec, Tomáš Stanˇek, and Matúš Tejišˇcák for their important remarks, to the rest of the Haskell community and to everybody that I forgot to mention. Thank you all. http://learnyouahaskell.com/ ∗Available online at . 3 Abstract The main goal of this thesis has been to provide a description of Haskell and basic information about source code analysis of this programming language. That includes Haskell standards, implementations, syntactic and lexical analysis, and its type system. Another objective was to write a library for syntactic and type analysis that can be used in further development. † Keywords Haskell, functional programming, code analysis, syntactic analysis, parsing, type evaluation, type-checking, type system †Source code available online at http://hasky.haskell.cz/. 4 Contents 1 Introduction 7 1.1 Why functional programming? . 7 1.2 Structure of the thesis . 8 2 The Haskell language 9 2.1 Main Haskell features . 10 2.1.1 Lazy evaluation . 10 2.1.2 Purity and referential transparency . 11 2.1.3 Strong type system with inference . 12 2.1.4 Monadic input and output . 12 2.2 Evolution of Haskell . 13 2.2.1 Early development . 13 2.2.2 The stable Haskell 98 . 14 2.2.3 Haskell Prime and the future of Haskell . 14 2.3 Haskell implementations . 15 2.3.1 GHC . 15 2.3.2 Hugs . 15 2.3.3 Yhc and nhc98 . 15 2.3.4 Other implementations . 16 5 3 Syntactic analysis 18 3.1 Haskell code analysis tools . 18 3.1.1 Parsec . 19 3.1.2 Happy . 19 3.1.3 Alex . 19 3.1.4 Other tools . 19 3.2 Hasky — the base of the Haskell interpreter . 20 3.2.1 Language.Haskell . 21 3.2.2 The source code of the Haskell 98 libraries . 21 3.2.3 The Haskell module system . 22 4 Type evaluation 23 4.1 Haskell’s type system in more detail . 23 4.1.1 Monomorphism . 23 4.1.2 Polymorphism . 24 4.1.3 Type classes . 24 4.1.4 Algebraic data types . 25 4.1.5 Type inference . 25 4.2 Type-checking libraries . 26 4.2.1 GHC API . 26 4.2.2 Typing Haskell in Haskell . 26 4.3 Type evaluation in Hasky . 26 5 Conclusions and future work 28 6 Chapter 1 Introduction Be careful, Haskell is addictive. The rst monad is free. —SHAE ERISSON ∗ 1.1 Why functional programming? For many years, functional programming did not belong to the category of main- stream paradigms. In fact, it was considered by the general programming public as an academic plaything. But modern functional languages, such as Haskell, Scala, F#, and Erlang, have recently gained popularity. When the hardware be- came cheaper than the programmer’s work — because of Moore’s law — code readability and maintainability started being considered more important than processor time and memory consumption. And with the arrival of affordable multicore processors, parallelization has become the general issue. There are some successful commercial projects which show that the use of func- tional programming can be a better way of writing programs than more estab- lished approaches (good examples are [1], [2, pages 6–8], and [3, pages 75–78]). The chief reason for this success lies in modularity that improves productivity in such large projects, which has been described in [4]. Besides that, because functional programming is based on lambda calculus, it is highly formal and thus suitable for applications in exact science. This is why functional programming matters and why we definitely need high-quality code analysis tools for these lan- guages. ∗One of the #haskell IRC channel founders (also known as shapr). 7 1.2 Structure of the thesis The following chapter gives a cursory overview of the Haskell programming lan- guage, describes its history and compares its implementations. The third chapter concerns itself with syntactic and lexical analysis issues. It features a description of current tools that are used for this purpose in Haskell. We will also introduce Hasky — our attempt to write the germ of the simplified Haskell interpreter. And finally, the fourth chapter is about Haskell’s type system and about its im- plementation in Hasky. 8 Chapter 2 The Haskell language Haskell is faster than C++, more concise than Perl, more regular than Python, more exible than Ruby, more typeful than C#, more robust than Java, and has absolutely nothing in common with PHP. —AUDREY TANG ∗ The only supported paradigm in Haskell is functional programming which be- longs to the family of declarative paradigms. The declarative paradigm is fun- damentally in contrast to the imperative paradigm that includes procedural and object-oriented programming. In imperative-based programming, we describe the program as a sequence of commands that change its state. In functional programming, we evaluate expressions and try to achieve a term in the normal form (the result). The transformation from one expression to another is executed by substituting function names with their corresponding definitions. So we are concerned with applying functions to values, just like in mathematics. Factorial computation is the classic example of a simple Haskell program. Let us define the factorial function fact as follows: fact 0 = 1 fact n = n * fact (n - 1) This is a common technique for defining a function in Haskell called pattern matching. The first definition says that the factorial of zero is one. The other defi- nition is a recursive one and defines the factorial of a non-zero number as the num- ber multiplied by the factorial of its predecessor. In other words, the factorial of a number n is defined as the product of all numbers that are less than or equal to n. This definition is not perfect — when we call the function with a negative ∗Author of Pugs, first functioning (and functional) implementation of Perl 6. 9 number, the program will get stuck in an infinite loop. There are better ways of defining the factorial function but this one is convenient for illustrative pur- poses. If we want to know the factorial of a number, say 3, we call the fact function with this parameter and the expression is evaluated step-by-step using the defini- tion: fact 3 3 * fact (3 - 1) 3 * 2 * fact (2 - 1) ∗ 3 * 2 * 1 fact (1 - 1) ∗ 3 * 2 * 1 * 1 ∗ 3 * 2 * 1 3 * 2 6 As a programming language, Haskell has a lot of interesting features. 2.1 Main Haskell features 2.1.1 Lazy evaluation The default evaluation strategy in Haskell is lazy evaluation. Along with normal evaluation, it is essentially opposite to the strict evaluation that is used in the ma- jority of programming languages. Instead of calling a function straight by value (or by similar way), non-strict approaches evaluate the function arguments only when it is necessary. This has several advantages — we can work with infinite structures and we do not have to evaluate unnecessary code. The main difference between normal and lazy evaluation strategies is that lazy evaluation uses intermediate results, which is usually more effective but comes at the cost of added overhead. In cases where the overhead is greater than ben- efits of lazy evaluation, laziness can be suppressed directly in the data definition (by a unary operator !), or in the code by the standard function seq and by the in- fix operator $!. For more information about adding strictness to Haskell see [5]. Generally, it does not matter what evaluation strategy we choose, it has to pro- vide the same result, but there is no guarantee that every strategy attains it. More eager strategies can evaluate code that the other strategies omitted and get stuck in an infinite loop or raise an error. We can show the differences between strate- gies, for example, when we define the function dbl, that doubles its first argu- ment, as dbl x y = x + x and then we call it with some expressions. 10 Example of strict evaluation Arguments are evaluated before the function application (the innermost first). dbl (3 * 7) (4096 * 1048576) dbl (3 * 7) 4294967296 dbl 21 4294967296 21 + 21 42 Example of normal evaluation Arguments are evaluated after the function application (the outermost first). dbl (3 * 7) (4096 * 1048576) (3 * 7) + (3 * 7) 21 + (3 * 7) 21 + 21 42 Example of lazy evaluation Arguments are evaluated after the function application and if the argument was already evaluated, the intermediate result is used. (It is executed in one step.) dbl (3 * 7) (4096 * 1048576) (3 * 7) + (3 * 7) 21 + 21 42 2.1.2 Purity and referential transparency Every Haskell function should be pure (except for input and output, see below). A pure function is basically any function, that always returns the same result for an argument and does not implicate any side effects. And because everything in Haskell is pure, the language is referentially transparent, so every expression can be substituted with its value without side effects.
Load more

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]
  • The Types, Roles, and Practices of Documentation in Data Analytics Open Source Software Libraries
    Computer Supported Cooperative Work (CSCW) https://doi.org/10.1007/s10606-018-9333-1 © The Author(s) 2018 The Types, Roles, and Practices of Documentation in Data Analytics Open Source Software Libraries A Collaborative Ethnography of Documentation Work R. Stuart Geiger1 , Nelle Varoquaux1,2 , Charlotte Mazel-Cabasse1 & Chris Holdgraf1,3 1Berkeley Institute for Data Science, University of California, Berkeley, 190 Doe Library, Berkeley, CA, 94730, USA (E-mail: [email protected]); 2Department of Statistics, Berkeley Institute for Data Science, University of California, Berkeley, Berkeley, CA, USA; 3Berkeley Institute for Data Science, Helen Wills Neuroscience Institute, University of California, Berkeley, Berkeley, CA, USA Abstract. Computational research and data analytics increasingly relies on complex ecosystems of open source software (OSS) “libraries” – curated collections of reusable code that programmers import to perform a specific task. Software documentation for these libraries is crucial in helping programmers/analysts know what libraries are available and how to use them. Yet documentation for open source software libraries is widely considered low-quality. This article is a collaboration between CSCW researchers and contributors to data analytics OSS libraries, based on ethnographic fieldwork and qualitative interviews. We examine several issues around the formats, practices, and challenges around documentation in these largely volunteer-based projects. There are many dif- ferent kinds and formats of documentation that exist around such libraries, which play a variety of educational, promotional, and organizational roles. The work behind documentation is similarly multifaceted, including writing, reviewing, maintaining, and organizing documentation. Different aspects of documentation work require contributors to have different sets of skills and overcome various social and technical barriers.
    [Show full text]
  • Dynamic Extension of Typed Functional Languages
    Dynamic Extension of Typed Functional Languages Don Stewart PhD Dissertation School of Computer Science and Engineering University of New South Wales 2010 Supervisor: Assoc. Prof. Manuel M. T. Chakravarty Co-supervisor: Dr. Gabriele Keller Abstract We present a solution to the problem of dynamic extension in statically typed functional languages with type erasure. The presented solution re- tains the benefits of static checking, including type safety, aggressive op- timizations, and native code compilation of components, while allowing extensibility of programs at runtime. Our approach is based on a framework for dynamic extension in a stat- ically typed setting, combining dynamic linking, runtime type checking, first class modules and code hot swapping. We show that this framework is sufficient to allow a broad class of dynamic extension capabilities in any statically typed functional language with type erasure semantics. Uniquely, we employ the full compile-time type system to perform run- time type checking of dynamic components, and emphasize the use of na- tive code extension to ensure that the performance benefits of static typing are retained in a dynamic environment. We also develop the concept of fully dynamic software architectures, where the static core is minimal and all code is hot swappable. Benefits of the approach include hot swappable code and sophisticated application extension via embedded domain specific languages. We instantiate the concepts of the framework via a full implementation in the Haskell programming language: providing rich mechanisms for dy- namic linking, loading, hot swapping, and runtime type checking in Haskell for the first time. We demonstrate the feasibility of this architecture through a number of novel applications: an extensible text editor; a plugin-based network chat bot; a simulator for polymer chemistry; and xmonad, an ex- tensible window manager.
    [Show full text]
  • What I Wish I Knew When Learning Haskell
    What I Wish I Knew When Learning Haskell Stephen Diehl 2 Version This is the fifth major draft of this document since 2009. All versions of this text are freely available onmywebsite: 1. HTML Version ­ http://dev.stephendiehl.com/hask/index.html 2. PDF Version ­ http://dev.stephendiehl.com/hask/tutorial.pdf 3. EPUB Version ­ http://dev.stephendiehl.com/hask/tutorial.epub 4. Kindle Version ­ http://dev.stephendiehl.com/hask/tutorial.mobi Pull requests are always accepted for fixes and additional content. The only way this document will stayupto date and accurate through the kindness of readers like you and community patches and pull requests on Github. https://github.com/sdiehl/wiwinwlh Publish Date: March 3, 2020 Git Commit: 77482103ff953a8f189a050c4271919846a56612 Author This text is authored by Stephen Diehl. 1. Web: www.stephendiehl.com 2. Twitter: https://twitter.com/smdiehl 3. Github: https://github.com/sdiehl Special thanks to Erik Aker for copyediting assistance. Copyright © 2009­2020 Stephen Diehl This code included in the text is dedicated to the public domain. You can copy, modify, distribute and perform thecode, even for commercial purposes, all without asking permission. You may distribute this text in its full form freely, but may not reauthor or sublicense this work. Any reproductions of major portions of the text must include attribution. The software is provided ”as is”, without warranty of any kind, express or implied, including But not limitedtothe warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authorsor copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, Arising from, out of or in connection with the software or the use or other dealings in the software.
    [Show full text]
  • Not All Patterns, but Enough
    Not All Patterns, But Enough Neil Mitchell, Colin Runciman York University Catch An Example • Is the following code safe?* risers :: Ord α→[α] → [[α]] risers [] = [] risers [x] = [[x]] risers (x:y:etc) = if x ≤ y then (x:s) : ss else [x] : (s : ss) where s:ss = risers (y : etc) > risers “Haskell” = [“Has”,“k”,“ell”] * Only people who haven’t seen this example in the paper! Using Catch > catch risers.hs Incomplete pattern on line 6 Program is safe • Catch is the associated implementation • Catch has proven the program is safe • Without any annotations The Pattern-Matching problem • Will a program crash when run? • May call error directly: error “doh!” • May call error indirectly: head [] • Partial pattern match: case False of True → 1 • GHC can warn on partial patterns • Catch conservatively checks a program will not crash at runtime • Even in the presence of partial patterns How Catch works First convert Haskell to first-order Core, using Yhc and Firstify Checker Exact Operates on first-order (ignoring laziness) Core language 3 constraint operators Constraint Language Conservative Describes a (possibly infinite) set of values Can replace constraint language Checker Terms • A constraint describes a set of values • x is a (:)-constructed value • A precondition is a constraint on arguments • In head x, x must be (:)-constructed • An entailment is a constraint on arguments to ensure a constraint on the result • If x is (:)-constructed, null x is False Checker Types • Opaque constraint type • data Constraint = … • Does an expression satisfy
    [Show full text]
  • Haddock User Guide I
    Haddock User Guide i Haddock User Guide Haddock User Guide ii Copyright © 2004 Simon Marlow Haddock User Guide iii COLLABORATORS TITLE : Haddock User Guide ACTION NAME DATE SIGNATURE WRITTEN BY Simon Marlow 2004-08-02 REVISION HISTORY NUMBER DATE DESCRIPTION NAME Haddock User Guide iv Contents 1 Introduction 1 1.1 Obtaining Haddock . .1 1.2 License . .2 1.3 Acknowledgements . .2 2 Invoking Haddock 3 2.1 Using literate or pre-processed source . .6 3 Documentation and Markup 7 3.1 Documenting a top-level declaration . .7 3.2 Documenting parts of a declaration . .8 3.2.1 Class methods . .8 3.2.2 Constructors and record fields . .8 3.2.3 Function arguments . .9 3.3 The module description . .9 3.4 Controlling the documentation structure . .9 3.4.1 Re-exporting an entire module . 10 3.4.2 Omitting the export list . 10 3.5 Named chunks of documentation . 11 3.6 Hyperlinking and re-exported entities . 11 3.7 Module Attributes . 12 3.8 Markup . 12 3.8.1 Paragraphs . 12 3.8.2 Special characters . 12 3.8.3 Character references . 13 3.8.4 Code Blocks . 13 3.8.5 Hyperlinked Identifiers . 13 3.8.6 Emphasis and Monospaced text . 13 3.8.7 Linking to modules . 14 3.8.8 Itemized and Enumerated lists . 14 3.8.9 Definition lists . 14 3.8.10 URLs . 14 3.8.11 Anchors . 14 Haddock User Guide v 4 Index 15 Abstract This document describes Haddock version 2.6.1, a Haskell documentation tool. Haddock User Guide 1 / 15 Chapter 1 Introduction This is Haddock, a tool for automatically generating documentation from annotated Haskell source code.
    [Show full text]
  • Haskhol: a Haskell Hosted Domain Specific Language for Higher-Order
    HaskHOL: A Haskell Hosted Domain Specific Language for Higher-Order Logic Theorem Proving BY c 2011 Evan Christopher Austin Submitted to the graduate degree program in Electrical Engineering & Computer Science and the Graduate Faculty of the University of Kansas in partial fulfillment of the requirements for the degree of Master of Science. Chairperson Dr. Perry Alexander Dr. Andy Gill Dr. Arvin Agah Date Defended: July 26, 2011 The Thesis Committee for Evan Christopher Austin certifies that this is the approved version of the following thesis: HaskHOL: A Haskell Hosted Domain Specific Language for Higher-Order Logic Theorem Proving Chairperson Dr. Perry Alexander Date Approved: July 26, 2011 ii Abstract HaskHOL is an implementation of a HOL theorem proving capability in Haskell. Motivated by a need to integrate theorem proving capabilities into a Haskell-based tool suite, HaskHOL began as a simple port of HOL Light to Haskell. However, Haskell's laziness, immutable data, and monadic extensions both complicate an implementation and enable a new feature class. This thesis describes HaskHOL, its motivation and implementation. Its use to implement a primitive, interactive theorem prover is explored and its performance is evaluated using a collection of intuitionistically valid problems. iii Acknowledgements Dr. Perry Alexander has served as a constant inspiration, mentor, and friend since very early in my college career. His guidance and the myriad of opportunities he has afforded me have kindled a passion for formal methods research that I can honestly say I would not have had otherwise. Dr. Andy Gill was the first professor I had at KU who challenged me to go above and beyond what was required for a course.
    [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]
  • Eclipsefp & Leksah
    EclipseFP & Leksah TAIMO PEELO 20.05.2009 EclipseFP • plugin for eclipse IDE platform • goal is to support all kinds of functional programming languages in Eclipse • current subprojects – Haskell module – Common module – Cohatoe module – OCaml module (admittedly dead) Downloading EclipseFP • http://eclipsefp.sourceforge.net/ – bit inactive, latest integration build 14 Sep 2008 – see downloads section • natural choice: try the latest – current prerequisites • JVM >= 5.0 • eclipse >= 3.2 • ghc ? – I had 6.8.2 Installing EclipseFP • downloaded the archive, followed the instructions – no dice, nothing new in Eclipse • argh, trying with update site then – http://eclipsefp.sf.net/updates – older version only, 0.10.0 Using EclipseFP • Help → Contents → Functional Programming • File → New Project → Haskell Project – ... and create new haskell module :) • first things noticed – error reporting not exhaustive – autocompletion (code assist) dumb – run in GHCi /hugs does nothing – “navigate to” (ctrl + click) not present!? Still Using EclipseFP • Haddock documentation generation – File → Export → Other → Haddock documentation Mysterious Cohatoe • that bastard is not installed with EclipseFP : – ... and is not available from update site – version 0.12.0 distributed as update site archive at • http://eclipsefp.sourceforge.net/cohatoe/index.html • contains runtime, SDK and examples • “but what does it do, mummy?” – Help → Contents → Cohatoe ... – "Contributing Haskell (code) to Eclipse"” Catching of the Cohatoe • Cohatoe Examples menu appeared... • EclipseFP has broken link to cohatoe-api – google for cohatoe-api_1.0.0.zip • Leif Frenzel has written Cohatoe quickstart – http://cohatoe.blogspot.com/ Taming of the Cohatoe • ps ax | grep haskell – haskellserver 57053 /usr/lib/ghc-6.8.2 – the beast is running :) Basic Cohatoe • Eclipse plugin extensions :) • consider Haskell function – doSmthWith :: String → String – ..
    [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]