GHC Reading Guide

Total Page:16

File Type:pdf, Size:1020Kb

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. compiler Pipeline stages process with intermediate languages GHC compiler Intermediate languages Haskell language Parser Renamer Haskell abstract syntax (HsSyn) Type checker Desugarer Core language Core to Core Core to STG STG language STG to Cmm Cmm language Cmm to Asm Assembly language (native or llvm) 1. compiler Each code is located in GHC compiler Parser [compiler/GHC/Parser] Renamer [compiler/GHC/Rename] Type checker [compiler/GHC/Tc] Desugarer [compiler/GHC/HsToCore] Core to Core [compiler/GHC/Core/Opt] Core to STG [compiler/GHC/CoreToStg] STG to Cmm [compiler/GHC/StgToCmm] Cmm to Asm [compiler/GHC/CmmTo{Asm, Llvm}] 1. Compiler Each pipeline stages 1. compiler Parser HsSyn Haskell source (Haskell Abstract Syntax) FunBind f x = inc x Parser f x HsApp (reader) inc x Abstracted - Parsing a Haskell source file - Checking user syntax errors - etc. 1. compiler Renamer HsSyn HsSyn FunBind FunBind f x HsApp Renamer f_1 x_2 HsApp inc x inc_3 x_2 Unique named - Resolving all of the identifiers - Rearranging infix expressions - Checking user scope errors - Building global environments - etc. 1. compiler Type checker HsSyn HsSyn FunBind FunBind f_1 x_2 HsApp Type checker f_1 x_2 HsApp @ Int -> Int @ Int inc_3 x_2 inc_3 x_2 @ Int -> Int @ Int Explicitly typed - Resolving/Inferring types - Decorating AST with types - Checking user type errors - etc. 1. compiler Desugarer HsSyn Core language FunBind Bind f_1 x_2 HsApp Desugarer Lam @ Int -> Int @ Int (HsToCore) App inc_3 x_2 @ Int -> Int @ Int Squeezed into λ calculus - Desugaring HsSyn to Core - Checking pattern-match overlap - etc. 1. compiler Core to Core Core language Core language Bind Bind Lam Core to Core App Optimized - Optimizing Core (simplifier, ...) - Checking typechecker's result with Lint - Tidying Core to Core - etc. 1. compiler Core to Stg Core language STG language StgBind Bind StgRhsClosure Core to STG StgCase register heap stack - Transforming Core to STG - etc. Operationally mapped 1. compiler STG to Cmm STG language Cmm language StgBind StgRhsClosure STG to Cmm StgCase (code gen) register heap stack - Optimizing STG Instruction blocked - Transforming STG to Cmm - etc. 1. compiler Cmm to Assembly Cmm language Assembly/LLVM language add $0x2, %rbx Cmm to Asm jmpq *0x0(%rbp) (native code gen) : Machine coded - Optimizing Cmm - Generating Asm - etc. 1. Compiler Intermediate language syntax 1. compiler HsSyn (Haskell abstract syntax) [compiler/GHC/Hs/Decls.hs] [compiler/GHC/Hs/Expr.hs] data HsDecl p data HsExpr p = TyClD ... -- Type or Class Declaration = HsVar ... | InstD ... -- Instance declaration | HsUnboundVar ... | HsConLikeOut ... | DerivD ... -- Deriving declaration | HsRecFld ... | ValD ... -- Value declaration | HsOverLabel ... | SigD ... -- Signature declaration | HsIPVar ... | KindSigD ... -- Standalone kind signature | HsOverLit ... | DefD ... -- 'default' declaration | HsLit ... | ForD ... -- Foreign declaration | HsLam ... | WarningD ... -- Warning declaration | HsLamCase ... | HsApp ... | AnnD ... -- Annotation declaration | HsAppType ... | RuleD ... -- Rule declaration | OpApp ... | SpliceD ... -- Splice declaration | NegApp ... | DocD ... -- Documentation comment declaration | HsPar ... | RoleAnnotD ... -- Role annotation declaration | SectionL ... | XHsDecl ... | SectionR ... | ExplicitTuple | ExplicitSum [compiler/GHC/Hs/Binds.hs] | HsCase ... data HsBindLR idL idR | HsIf ... = FunBind ... -- Function-like Binding | HsMultiIf ... | HsLet ... | PatBind ... -- Pattern Binding | HsDo ... | VarBind ... -- Variable Binding | ExplicitList | AbsBinds ... -- Abstraction Bindings | RecordCon | PatSynBind ... -- Patterns Synonym Binding | RecordUpd | XHsBindsLR ... | ExprWithTySig | ArithSeq : An abstract syntax corresponding to Haskell user source. 1. compiler Core language [compiler/GHC/Core.hs] type CoreProgram = [CoreBind] type CoreBndr = Var type CoreExpr = Expr CoreBndr type CoreArg = Arg CoreBndr type CoreBind = Bind CoreBndr type CoreAlt = Alt CoreBndr data Expr b = Var Id -- Variable | Lit Literal -- Literal | App (Expr b) (Arg b) -- Application | Lam b (Expr b) -- Lambda abstraction | Let (Bind b) (Expr b) -- Variable binding | Case (Expr b) b Type [Alt b] -- Pattern match | Cast (Expr b) Coercion -- Cast | Tick (Tickish Id) (Expr b) -- Internal note | Type Type -- Type | Coercion Coercion -- Coercion A tiny explicitly-typed functional language. Only ten data constructors based on System FC. 1. compiler STG language [compiler/GHC/Stg/Syntax.hs] data GenStgTopBinding pass = StgTopLifted (GenStgBinding pass) | StgTopStringLit Id ByteString data GenStgBinding pass = StgNonRec (BinderP pass) (GenStgRhs pass) | StgRec [(BinderP pass, GenStgRhs pass)] data GenStgRhs pass = StgRhsClosure (XRhsClosure pass) CostCentreStack !UpdateFlag [BinderP pass] (GenStgExpr pass) | StgRhsCon CostCentreStack DataCon [StgArg] data GenStgExpr pass = StgApp Id [StgArg] | StgLit Literal | StgConApp DataCon [StgArg] [Type] | StgOpApp StgOp [StgArg] Type | StgLam (NonEmpty (BinderP pass)) StgExpr | StgCase (GenStgExpr pass) (BinderP pass) AltType [GenStgAlt pass] | StgLet (XLet pass) (GenStgBinding pass) (GenStgExprpass) | StgLetNoEscape (XLetNoEscape pass) (GenStgBinding pass) (GenStgExpr pass) | StgTick (Tickish Id) (GenStgExpr pass) A very small purely-functional language with the abstract machine (STG-machine) semantics. 1. compiler Cmm language [compiler/GHC/Cmm.hs] type CmmProgram = [CmmGroup] type CmmGroup = GenCmmGroup CmmStatics CmmTopInfo CmmGraph type CmmGraph = GenCmmGraph CmmNode [compiler/GHC/Cmm/Node.hs] data CmmNode e x where CmmEntry ... -- Entry CmmComment ... -- Comment CmmTick ... -- Tick annotation CmmUnwind ... -- Unwind pseudo-instruction CmmAssign :: !CmmReg -> !CmmExpr -> CmmNode O O -- Assign to register CmmStore ... -- Assign to memory location CmmUnsafeForeignCall ... -- An unsafe foreign call CmmBranch ... -- Goto another block CmmCondBranch ... -- Conditional branch CmmSwitch ... -- Switch CmmCall ... -- A native call or tail call CmmForeignCall ... -- A safe foreign call [compiler/GHC/Cmm/Expr.hs] data CmmExpr = CmmLit CmmLit -- Literal | CmmLoad !CmmExpr !CmmType -- Read memory location | CmmReg !CmmReg -- Contents of register | CmmMachOp MachOp [CmmExpr] -- Machine operation (+, -, *, etc.) | CmmStackSlot Area {-# UNPACK #-} !Int | CmmRegOff !CmmReg Int A low-level imperative language with an explicit stack. 1. Compiler Call graph 1. compiler An example of a call graph main [ghc/Main.hs] main' [ghc/Main.hs] oneShot [compiler/GHC/Driver/Pipeline.hs] compileFile [compiler/GHC/Driver/Pipeline.hs] runPipeline [compiler/GHC/Driver/Pipeline.hs] runPipeline' [compiler/GHC/Driver/Pipeline.hs] pipeLoop [compiler/GHC/Driver/Pipeline.hs] runHookedPhase [compiler/GHC/Driver/Pipeline.hs] runPhase [compiler/GHC/Driver/Pipeline.hs] hscIncrementalCompile [compiler/GHC/Driver/Main.hs] hscIncrementalFrontend [compiler/GHC/Driver/Main.hs] hsc_typecheck [compiler/GHC/Driver/Main.hs] hscParse' [compiler/GHC/Driver/Main.hs] Parser parseModule [compiler/GHC/Parser.y] tcRnModule' [compiler/GHC/Driver/Main.hs] Renamer and tcRnModule [compiler/GHC/Tc/Module.hs] Type checker tcRnModuleTcRnM [compiler/GHC/Tc/Module.hs] tcRnSrcDecls [compiler/GHC/Tc/Module.hs] tc_rn_src_decls [compiler/GHC/Tc/Module.hs] rnTopSrcDecls [compiler/GHC/Tc/Module.hs] tcTopSrcDecls [compiler/GHC/Tc/Module.hs] finish [compiler/GHC/Driver/Main.hs] hscDesugar' [compiler/GHC/Driver/Main.hs] Desugarer deSugar [compiler/GHC/HsToCore.hs] hscSimplify' [compiler/GHC/Driver/Main.hs] Core to Core core2core [compiler/GHC/Core/Opt/Pipeline.hs] hscGenHardCode [compiler/GHC/Driver/Main.hs]
Recommended publications
  • 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]
  • The Glasgow Haskell Compiler User's Guide, Version 4.08
    The Glasgow Haskell Compiler User's Guide, Version 4.08 The GHC Team The Glasgow Haskell Compiler User's Guide, Version 4.08 by The GHC Team Table of Contents The Glasgow Haskell Compiler License ........................................................................................... 9 1. Introduction to GHC ....................................................................................................................10 1.1. The (batch) compilation system components.....................................................................10 1.2. What really happens when I “compile” a Haskell program? .............................................11 1.3. Meta-information: Web sites, mailing lists, etc. ................................................................11 1.4. GHC version numbering policy .........................................................................................12 1.5. Release notes for version 4.08 (July 2000) ........................................................................13 1.5.1. User-visible compiler changes...............................................................................13 1.5.2. User-visible library changes ..................................................................................14 1.5.3. Internal changes.....................................................................................................14 2. Installing from binary distributions............................................................................................16 2.1. Installing on Unix-a-likes...................................................................................................16
    [Show full text]
  • The Glorious Glasgow Haskell Compilation System User's Guide
    The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.8.2 i The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.8.2 The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.8.2 ii COLLABORATORS TITLE : The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.8.2 ACTION NAME DATE SIGNATURE WRITTEN BY The GHC Team April 11, 2014 REVISION HISTORY NUMBER DATE DESCRIPTION NAME The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.8.2 iii Contents 1 Introduction to GHC 1 1.1 Obtaining GHC . .1 1.2 Meta-information: Web sites, mailing lists, etc. .1 1.3 Reporting bugs in GHC . .2 1.4 GHC version numbering policy . .2 1.5 Release notes for version 7.8.1 . .3 1.5.1 Highlights . .3 1.5.2 Full details . .5 1.5.2.1 Language . .5 1.5.2.2 Compiler . .5 1.5.2.3 GHCi . .6 1.5.2.4 Template Haskell . .6 1.5.2.5 Runtime system . .6 1.5.2.6 Build system . .6 1.5.3 Libraries . .6 1.5.3.1 array . .6 1.5.3.2 base . .7 1.5.3.3 bin-package-db . .7 1.5.3.4 binary . .7 1.5.3.5 bytestring . .7 1.5.3.6 Cabal . .8 1.5.3.7 containers . .8 1.5.3.8 deepseq . .8 1.5.3.9 directory . .8 1.5.3.10 filepath . .8 1.5.3.11 ghc-prim . .8 1.5.3.12 haskell98 .
    [Show full text]
  • Freebsd Foundation February 2018 Update
    FreeBSD Foundation February 2018 Update Upcoming Events Message from the Executive Director Dear FreeBSD Community Member, AsiaBSDCon 2018 Welcome to our February Newsletter! In this newsletter you’ll read about FreeBSD Developers Summit conferences we participated in to promote and teach about FreeBSD, March 8-9, 2018 software development projects we are working on, why we need Tokyo, Japan funding, upcoming events, a release engineering update, and more. AsiaBSDCon 2018 Enjoy! March 8-11, 2018 Tokyo, Japan Deb SCALE 16x March 8-11, 2018 Pasadena, CA February 2018 Development Projects FOSSASIA 2018 March 22-25, 2018 Update: The Modern FreeBSD Tool Chain: Singapore, Singapore LLVM's LLD Linker As with other BSD distributions, FreeBSD has a base system that FreeBSD Journal is developed, tested and released by a single team. Included in the base system is the tool chain, the set of programs used to build, debug and test software. FreeBSD has relied on the GNU tool chain suite for most of its history. This includes the GNU Compiler Collection (GCC) compiler, and GNU binutils which include the GNU "bfd" linker. These tools served the FreeBSD project well from 1993 until 2007, when the GNU project migrated to releasing its software under the General Public License, version 3 (GPLv3). A number of FreeBSD developers and users objected to new restrictions included in GPLv3, and the GNU tool chain became increasingly outdated. The January/February issue of the FreeBSD Journal is now available. Don't miss articles on The FreeBSD project migrated to Clang/LLVM for the compiler in Tracing ifconfig Commands, Storage FreeBSD 10, and most of GNU binutils were replaced with the ELF Tool Multipathing, and more.
    [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]
  • Hassling with the IDE - for Haskell
    Hassling with the IDE - for Haskell This guide is for students that are new to the Haskell language and are in need for a proper I​ntegrated ​D​evelopment ​E​nvironment (IDE) to work on the projects of the course. This guide is intended for Windows users. It may work similarly on Linux and iOS. For more information, see: - https://www.haskell.org/platform/mac.html​ for iOS - https://www.haskell.org/downloads/linux/​ for Linux For any errors, please contact me at ​[email protected]​. Changelog 04/09/2019 Initial version 24/08/2020 Updated contents for the year 2020 / 2021, thanks to Bernadet for pointing it out 1. Installing Visual Studio Code Visual Studio Code (VSC) is a lightweight, but rather extensive, code editor. We’ll talk about its features throughout this guide. You can download VSC at: https://code.visualstudio.com/download Once installed, take note of the sidebar on the left. From top to bottom, it contains: - Explorer (Ctrl + Shift + E) - Search (Ctrl + Shift + F) - Source control (Ctrl + Shift + G) - Debug (Ctrl + Shift + D) - Extensions (Ctrl + Shift + X) The ​bold​ options are important to remember. They will be mentioned throughout this document. 2. Installing GHC (and stack / cabal) on Windows Download the Glasgow Haskell Compiler (GHC). This compiler is used throughout this course and any other course that uses Haskell. You can find its download instructions at: https://www.haskell.org/platform/windows.html The download link recommends you to use Chocolatey. ​Chocolatey is an open source project that provides developers and admins alike a better way to manage Windows software.
    [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]
  • Installing Haskell
    Installing Haskell 0.1 Learning programming Throughout this course you’ll be learning to program in Haskell. One way of learning a programming language is to start with formal syntax and semantics (although very few programming languages have formal semantics). This is very different from how most people learn languages, be it natural or computer languages. A child learns the meaning of words and sentences not by analyzing their structure and looking up the definitions in Wikipedia. In fact, a child’s understanding of language is very similar to how we work in category theory. We derive the meaning of objects from the network of interactions with other objects. This is easy in mathematics, where we can say that an object is defined by the totality of its interactions with possibly infinite set of other objects (we’ll see that when we talk about the Yoneda lemma). In real life we don’t have the time to explore the infinity, so we can only approximate this process. We do this by living on credit. This is how we are going to learn Haskell. We’ll be using things, from day one, without fully understanding their meaning, thus constantly incurring a conceptual debt. Some of this debt will be paid later. Some of it will stay with us forever. The alternative would be to first learn about cartesian closed categories and domain theory, formally define simply typed lambda calculus, build its categorical model, and only then wave our hands a bit and claim that at its core Haskell approximates this model.
    [Show full text]
  • Secrets of the Glasgow Haskell Compiler Inliner
    Secrets of the Glasgow Haskell Compiler inliner Simon Marlow Simon Peyton Jones Microsoft Research Ltd, Cambridge Microsoft Research Ltd, Cambridge [email protected] [email protected] Septemb er 1, 1999 A ma jor issue for any compiler, esp ecially for one that Abstract inlines heavily,is name capture. Our initial brute-force solution involved inconvenient plumbing, and wehave Higher-order languages, such as Haskell, encourage the pro- now evolved a simple and e ective alternative Sec- grammer to build abstractions by comp osing functions. A tion 3. go o d compiler must inline many of these calls to recover an eciently executable program. At rst wewere very conservative ab out inlining recur- sive de nitions; that is, we did not inline them at all. In principle, inlining is dead simple: just replace the call But we found that this strategy o ccasionally b ehaved of a function by an instance of its b o dy. But any compiler- very badly. After a series of failed hacks we develop ed writer will tell you that inlining is a black art, full of delicate a simple, obviously-correct algorithm that do es the job compromises that work together to give go o d p erformance b eautifully Section 4. without unnecessary co de bloat. Because the compiler do es so much inlining, it is im- The purp ose of this pap er is, therefore, to articulate the p ortant to get as much as p ossible done in each pass key lessons we learned from a full-scale \pro duction" inliner, over the program.
    [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]