DOCSLIB.ORG

Rules Haskell Documentation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Rules Haskell Documentation rules_haskell Documentation Tweag I/O Aug 30, 2021 Contents: 1 Is Bazel right for me? 3 1.1 Rule of thumb..............................................3 1.2 Rationale.................................................3 2 Introduction to Bazel: Building a Haskell project5 2.1 What you’ll learn.............................................5 2.2 Before you begin.............................................5 2.3 Build with Bazel.............................................6 2.4 Refine your Bazel build.........................................8 2.5 Use labels to reference targets...................................... 11 2.6 Further reading.............................................. 11 3 Common Haskell Build Use Cases 13 3.1 Starting a new project.......................................... 13 3.2 Making rules_haskell available..................................... 13 3.3 Picking a compiler............................................ 14 3.4 Loading targets in a REPL........................................ 15 3.5 Configuring IDE integration with ghcide................................ 15 3.6 Building Cabal packages......................................... 17 3.7 Building Cabal packages (using Nix).................................. 21 3.8 Generating API documentation..................................... 21 3.9 Linting your code............................................ 22 3.10 Using conditional compilation...................................... 22 3.11 Using source code pre-processors.................................... 23 3.12 Checking code coverage......................................... 23 3.13 Persistent Worker Mode (experimental)................................. 24 3.14 Building fully-statically-linked binaries................................. 25 3.15 Containerization with rules_docker................................... 27 3.16 Cross-compilation............................................ 30 i ii rules_haskell Documentation Bazel is a tool for automating the building and the testing of software. Follow this guide to get started building small Haskell projects using Bazel. For a deeper dive and solutions to more advanced use cases, see Common Haskell Build Use Cases. Refer to the Bazel documentation for more about Bazel. Requirements: • Bazel: See the start script for versions that are known to be compatible. Contents: 1 rules_haskell Documentation 2 Contents: CHAPTER 1 Is Bazel right for me? Nearly as many build tools exist as there are programming languages out there. C++ has Autotools/Make, CMake and many others. Java has Ant, Maven, Gradle and several more. Haskell has Cabal, Stack, Shake and several more. Each of these originated in a given language community but are in some cases generic enough to support building any language. Are any of them the right choice for your use case? Should you be combining several systems? That’s what this document should help you answer. 1.1 Rule of thumb If a combination of the following apply, then you’re better off using Cabal or Stack: • your project is an independently publishable single library, or small set of libraries; • your project is open source code and has at most small static assets (hence publishable on Hackage); • your project is nearly entirely Haskell code with perhaps a little bit of C; • your project has many dependencies on other packages found on Hackage but few if any system dependencies (like zlib, libpng etc); Bazel works well for the following use cases: • projects that cannot be hosted on Hackage (games with large static assets, proprietary code etc); • projects with a very large amount of code hosted in a single repository; • projects in which you or your team are writing code in two or more languages (e.g. Haskell/PureScript, or Haskell/Java, or Haskell/C++/FORTRAN); 1.2 Rationale For all the benefits it can bring, Bazel also has an upfront cost. Don’t pay that cost if the benefits don’t justify it. 3 rules_haskell Documentation If you don’t have much code to build, any build tool will do. Build issues like lack of complete reproducibility are comparatively easier to debug, and working around build system bugs by wiping the entire build cache first is entirely viable in this particular case. So might as well use low-powered Haskell-native build tools that ship with GHC. You won’t need sandboxed build actions to guarantee build system correctness, completely hermetic builds for good reproducibility, build caching, test result caching or distributed builds for faster build and test times. Those features start to matter for larger projects, and become essential for very large monorepos. Why exactly do these features matter? • Hermetic builds are builds that do not take any part of the host’s system configuration (set of installed system libraries and their versions, content of /etc, OS version, etc) as an input. If all build actions are deterministic, hermeticity guarantees that builds are reproducible anywhere, anytime. More developers on a project means more subtly different system configurations to cope with. The more system configurations, the more likely that the build will fail in one of these configurations but not in others. Unless the build is completely hermetic. • Sandboxing build actions guarantees that all inputs to all build actions are properly declared. This helps prevent build system correctness bugs, which are surprisingly and exceedingly common in most non-sandboxing build systems, especially as the build system becomes more complex. When a build system might be incorrect, users regularly have to wipe the entire build cache to work around issues. As the codebase becomes very large, rebuilding from scratch can cost a lot of CPU time. • Distributed build caches make building the code from a fresh checkout trivially fast. Continuous integration populates the build cache at every branch push, so that building all artifacts from fresh checkouts seldom needs to actually build anything at all locally. In the common case, builds become network-bound instead of CPU-bound. • Distributed build action execution mean that average build times can stay constant even as the codebase grows, because you can seamlessly distribute the build on more machines. • Test result caching is the key to keeping continuous integration times very low. Only those tests that depend on code that was modified need be rerun. On their own hermetic and sandboxed builds can already save quite a few headaches. But crucially, without them one can’t even hope to have any of the other features that follow them above. 4 Chapter 1. Is Bazel right for me? CHAPTER 2 Introduction to Bazel: Building a Haskell project In this tutorial, you’ll learn the basics of building Haskell applications with Bazel. You will set up your workspace and build a simple Haskell project that illustrates key Bazel concepts, such as targets and BUILD.bazel files. After completing this tutorial, take a look at Common Haskell build use cases for information on more advanced concepts such as writing and running Haskell tests. 2.1 What you’ll learn In this tutorial you’ll learn how to: • build a target, • visualize the project’s dependencies, • split the project into multiple targets and packages, • control target visibility across packages, • reference targets through labels. 2.2 Before you begin On a Unix system you will need the following tools installed. • gcc • libffi • libgmp • libtinfo5 • make 5 rules_haskell Documentation • python3 (python also needs to be available in $PATH. Depending on your distribution, this might require installing the python meta-package, which might use Python 2 or 3, rules_haskell works with both.) On Ubuntu you can obtain them by installing the following packages. build-essential libffi-dev libgmp-dev libtinfo5 libtinfo-dev python python3 On Windows you will need. • msys2 • python3 Next, install Bazel if you don’t have it installed already. Then, retrieve the rules_haskell GitHub repository: git clone https://github.com/tweag/rules_haskell/ The sample project for this tutorial is in the tutorial directory and is structured as follows: rules_haskell tutorial WORKSPACE main BUILD.bazel Main.hs lib BUILD.bazel Bool.hs The first thing to do is to: $ cd tutorial If you use the NixOS distribution, also run the following command: $ echo 'test --host_platform=@io_tweag_rules_nixpkgs//nixpkgs/platforms:host' >> . ,!bazelrc.local 2.3 Build with Bazel 2.3.1 Set up the workspace Before you can build a project, you need to set up its workspace. A workspace is a directory that holds your project’s source files and Bazel’s build outputs. It also contains files that Bazel recognizes as special: • the WORKSPACE file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project’s directory structure, • one or more BUILD.bazel files, which tell Bazel how to build different parts of the project. (A directory within the workspace that contains a BUILD.bazel file is a package. You will learn about packages later in this tutorial.) To designate a directory as a Bazel workspace, create a file named WORKSPACE in that directory. This file defines external dependencies. When Bazel builds the project, all inputs and dependencies must be in the same workspace. Files residing in different workspaces are independent of one another unless linked, which is beyond the scope of this tutorial. 6 Chapter 2. Introduction to Bazel: Building a Haskell project rules_haskell Documentation 2.3.2 Understand the WORKSPACE file The file tutorial/WORKSPACE defines how to obtain rules_haskell. This file only works
Load more

Recommended publications
  • The Snap Framework: a Web Toolkit for Haskell
    The Functional Web The Snap Framework A Web Toolkit for Haskell Gregory Collins • Google Switzerland Doug Beardsley • Karamaan Group askell is an advanced functional pro- the same inputs, always produce the same out- gramming language. The product of more put. This property means that you almost always H than 20 years of research, it enables rapid decompose a Haskell program into smaller con- development of robust, concise, and fast soft- stituent parts that you can test independently. ware. Haskell supports integration with other Haskell’s ecosystem also includes many power- languages and has loads of built-in concurrency, ful testing and code-coverage tools. parallelism primitives, and rich libraries. With Haskell also comes out of the box with a set its state-of-the-art testing tools and an active of easy-to-use primitives for parallel and con- community, Haskell makes it easier to produce current programming and for performance pro- flexible, maintainable, high-quality software. filing and tuning. Applications built with GHC The most popular Haskell implementation is enjoy solid multicore performance and can han- the Glasgow Haskell Compiler (GHC), a high- dle hundreds of thousands of concurrent net- performance optimizing native-code compiler. work connections. We’ve been delighted to find Here, we look at Snap, a Web-development that Haskell really shines for Web programming. framework for Haskell. Snap combines many other Web-development environments’ best fea- What’s Snap? tures: writing Web code in an expressive high- Snap offers programmers a simple, expressive level language, a rapid development cycle, fast Web programming interface at roughly the same performance for native code, and easy deploy- level of abstraction as Java servlets.
    [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 Haskell Cabal
    The Haskell Cabal A Common Architecture for Building Applications and Tools Isaac Jones Simon Peyton Jones Simon Marlow Malcolm Wallace Ross Patterson The Haskell Library and Tools Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. This document specifies the Common Architecture for Building Applications and Tools(Cabal), which contributes to the goals of the Haskell Library and Tools Infrastructure Project. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the Library Infrastructure project. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. The Cabal has been discussed by the implementors of GHC, Nhc98, and Hugs, all of whom are prepared to implement it. The proposal is now open for wider debate. Please contribute by emailing <[email protected]>. 1 The Haskell Cabal 1. The Haskell Package System: goals The Haskell Package System (Cabal) has the following main goal: to specify a standard way in which a Haskell tool can be packaged, so that it is easy for consumers to use it, or re-package it, regardless of the Haskell implementation or installation platform.
    [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]
  • The Haskell Cabal
    The Haskell Cabal A Common Architecture for Building Applications and Tools Isaac Jones Simon Peyton Jones Simon Marlow Malcolm Wallace Ross Patterson The Haskell Library and Tools Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. This document specifies the Common Architecture for Building Applications and Tools(Cabal), which contributes to the goals of the Haskell Library and Tools Infrastructure Project. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the Library Infrastructure project. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. The Cabal has been discussed by the implementors of GHC, Nhc98, and Hugs, all of whom are prepared to implement it. The proposal is now open for wider debate. Please contribute by emailing <[email protected]>. 1. The Haskell Package System: goals The Haskell Package System (Cabal) has the following main goal: to specify a standard way in which a Haskell tool can be packaged, so that it is easy for consumers to use it, or re-package it, regardless of the Haskell 1 The Haskell Cabal implementation or installation platform.
    [Show full text]
  • The Glorious Glasgow Haskell Compilation System User's Guide
    The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.0.3 i The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.0.3 The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.0.3 ii COLLABORATORS TITLE : The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.0.3 ACTION NAME DATE SIGNATURE WRITTEN BY The GHC Team March 27, 2011 REVISION HISTORY NUMBER DATE DESCRIPTION NAME The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.0.3 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.0.3 . .3 1.6 Release notes for version 7.0.2 . .3 1.6.1 Compiler . .3 1.6.2 GHCi . .3 1.6.3 Runtime system . .4 1.6.4 Build system . .4 1.6.5 Haddock . .4 1.6.6 Libraries . .4 1.6.6.1 array . .4 1.6.6.2 base . .4 1.6.6.3 bin-package-db . .4 1.6.6.4 bytestring . .4 1.6.6.5 Cabal . .4 1.6.6.6 containers . .4 1.6.6.7 directory . .5 1.6.6.8 extensible-exceptions . .5 1.6.6.9 filepath . .5 1.6.6.10 ghc-binary . .5 1.6.6.11 ghc-prim . .5 1.6.6.12 haskell98 . .5 1.6.6.13 haskell2010 . .5 1.6.6.14 hpc .
    [Show full text]
  • 1 the Standard Haskell Infrastructure [Infrastructure.Tex 2011-11-17]
    infrastructure.tex 2011-11-17 haskell doc September 6, 2012 1 1 The standard Haskell infrastructure [infrastructure.tex 2011-11-17] Announcement Forword I shouldn’t say, that the Haskell Cabal is a mess. Maybe, it is a Haskell amateurs write Haskell modules, Haskell professionals good design and the cabal command is already a powerful and write packages. versatile tool. But its documentation is still a mess: all the good Modules are part of the Haskell language in the narrower sense Haskell books out there either don’t deal with packages at all, of a well–defined syntax and pretty well–explained semantics. or they sketch typical examples without explaining a lot. And Packages are defined by a standard beyond, namely the Ca- the Cabal User Guide itself is rather an overwhelming reference bal, the Common Architecture for Building Applications and Li- than a tutorial. braries. I should understand the matter to write this text. But I wrote In the sequel, we try to shed some light on the standard Haskell it, because I don’t. And nothing out there fills the void, so far. infrastructure. So please, don’t be polite, but criticize. Especially, if you find it (1) The Haskell Platform is the common ground for all Haskellers useful. and we give a summarizing overview of its ingredients. (2) Cabal *** CONTINUE HERE *** libraries.tex 2009-02-14, 2011-10-27 haskell doc September 6, 2012 2 The Standard Haskell Environment Each of the mentioned applications comes with a built–in man- ual, which shows when you add --help to the commands name.
    [Show full text]
  • An Integrated Development Environment for Haskell
    Leksah: An Integrated Development Environment for Haskell Jürgen Nicklisch-Franken Hamish Mackenzie July 21, 2009 Contents 1 Introduction 4 1.1 Further Information . .4 1.2 Release Notes . .4 1.2.1 Version 0.6 Beta Release Juli 2009 . .4 1.2.2 Version 0.4 Beta Release February/March 2009 . .5 1.2.3 Version 0.1 Alpha Release February 2008 . .5 2 Installing Leksah 6 2.1 Generic Installation Instructions . .6 2.1.1 Install GHC (Glasgow Haskell Compiler) . .6 2.1.2 Install Cabal . .6 2.1.3 Install Gtk2Hs . .6 2.1.4 Install Leksah . .7 2.1.5 Where Things Are Installed . .7 2.1.6 Post installation steps . .7 2.2 OS X (using MacPorts) . .7 2.2.1 Install MacPorts . .7 2.2.2 Set up ~/.prole . .8 2.2.3 Update MacPorts . .8 2.2.4 Set Variants To Use Quartz (Optional) . .8 2.2.5 Install . .8 2.2.6 Make It Look Nice . .8 2.2.7 Point Leksah At The Source . .9 2.3 Ubuntu . .9 2.3.1 Install Prerequisites . .9 2.3.2 Install GHC (Once 6.10.1 is in the universe repository) . .9 2.3.3 Install Cabal . .9 1 2.3.4 Install Gtk2Hs . 10 2.3.5 Add Cabal To Your PATH . 10 2.3.6 Install Leksah . 10 2.4 MS Windows . 10 3 First start of Leksah 12 3.1 Hello World example . 13 4 The Editor 16 4.1 Find and Replace . 16 4.1.1 Grep . 17 4.2 Source Candy .
    [Show full text]
  • The Haskell Cabal a Common Architecture for Building Applications and Libraries
    The Haskell Cabal A Common Architecture for Building Applications and Libraries Isaac Jones Galois Connections Abstract Many programming languages and operating systems have a means of bundling to- gether related source files, libraries, documentation, or executables for distribution. Such packaging systems contribute to a developer’s ability to write complex soft- ware, since they can build upon reusable components which can be easily installed on an end-user’s system. In addition, ease of installation can greatly increase initial adoption of a piece of software in user communities. The Haskell Cabal is an architecture for building and installing any tool developed in the Haskell language. It specifies a command-line interface that makes it easy for end users to build and install libraries and applications, and supports tool authors by providing a library which implements this interface. Cabal draws inspiration from a wide variety of tools and may in turn inspire tools for distribution of software in other functional programming languages. It is an evolving piece of open source software, and as such, we welcome discussion and contributions from any user community with an interest in its direction. Cabal was officially released with the latest version of three Haskell compilers, GHC 6.4, Hugs98 March 2005, and nhc98 1.18. 1 Its interface has already been used to implement a number of layered tools, and many newly released software tools use Cabal’s API as their build system. 1 INTRODUCTION The Haskell Cabal is an architecture for building and installing any tool developed in the Haskell language. It thereby facilitates distribution of any such tool.
    [Show full text]
  • Purely Functional Package Management With
    PURELY FUNCTIONAL PACKAGE MANAGEMENT WITH NIX Eric Rasmussen / @theerasmas January 19, 2015 WHO AM I OSS contributor haskell/python/javascript developer works on a hybrid dev/ops team prior LUGOD speaker (not about Linux) PACKAGING: THE GOOD PARTS installs in one click/command automatic dependency resolution there's just one problem PACKAGING: THE BAD PARTS dependency hell obscure errors high maintenance costs TL;DR PACKAGING IS HARD PACKAGE MANAGERS CHOICES (OS) dpkg/apt rpm/yum pacman homebrew mac ports various app stores CHOICES (PL) easy_install pip go get maven npm rubygems sbt cabal package.el cpan pear pecl DO WE REALLY NEED ANOTHER? (via http://xkcd.com/927/) INTRODUCING NIX new model for package management introduced in Eelco Dolstra's PhD Thesis (2006) based on functional programming principles WHAT NIX OFFERS minimal and portable declarative reproducible builds deterministic FUNCTIONAL PURITY Function takes inputs and produces output Ex: Addition takes two numbers and makes a new one 40 + 2 = 42 FUNCTIONAL PURITY Most programming languages don't enforce this! 40 + 2 = = new log file with debug output = database calls = HTTP service calls... = 42, maybe? NIX PACKAGES ARE PURE Input: other packages, configuration options Output: a package EXAMPLE: GCC /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-gcc-4.3.6/ inside the prefix: bin, lib, share, ... directories r8vvq9kq18pz08v249h8my6r9vs7s0n3 is a hash of function inputs PURITY IN NIX no global install directories (/usr, /bin) /nix/store is immutable (mounted read-only) nix expressions
    [Show full text]
  • Setting up Haskell IDE for Atom
    Setting up Haskell IDE for Atom September 3, 2016 1 Note to Windows/Mac/DICE(Linux) Users The steps of configuration of Windows is similar to those of Mac/DICE(Linux). All you need is to install some required plugins of Atom and binary dependencies of Haskell. The aim is to set up the atom for a useful Haskell IDE by ide-haskell plugin [1]. 2 Plugins of Atom First, following five plugins should be installed, as well as ide-haskell. Although you may not need some of them, it is strongly suggested to install them all. • language-haskell - Required • ide-haskell-cabal - Use this plugin to build and launch Haskell projects • haskell-ghc-mod - Use this plugin to type-check your code on save and add type highlights on mouseover • autocomplete-haskell [2] - Use this plugin to autocomplete code • ide-haskell-repl [3] - It provides a way to interact with ghci from Atom The steps of installation are really easy. Once the Atom has been isntalled, you can simply type the following command in terminal of Mac/DICE(Linux) or cmd of Windows: $ apm install language−haskell haskell −ghc−mod ide−h a s k e l l −cabal ide−haskell autocomplete−h a s k e l l ide−h a s k e l l −r e p l Listing 1: Commands of installation On the other hand, you can also install them through GUI of Atom. Click the menu: Packages − > Settings View − > Install Packages/Themes of Atom. Then you may find the installation interface with a search bar at figure 1.
    [Show full text]
  • The Glasgow Haskell Compiler the Architecture of Open Source Applications, Volume 2 ∗ DRAFT Chapter
    The Glasgow Haskell Compiler The Architecture of Open Source Applications, Volume 2 ∗ DRAFT chapter Simon Marlow Simon Peyton Jones March 16, 2012 1 Introduction The Glasgow Haskell Compiler (GHC) started as part of an academic research project funded by the UK government at the beginning of the 1990's, with several goals in mind: • To make freely available a robust and portable compiler for Haskell that generates high performance code; • To provide a modular foundation that other researchers can extend and develop; • To learn how real programs behave, so that we can design and build better compilers. GHC is now over 20 years old, and has been under continuous active devel- opment since its inception. Today, GHC releases are downloaded by hundreds of thousands of people, the online repository of Haskell libraries has over 3,000 packages, GHC is used to teach Haskell in many undergraduate courses, and there are a growing number of instances of Haskell being depended upon com- mercially. Over its lifetime GHC has generally had around two or three active develop- ers, although the number of people who have contributed some code to GHC is in the hundreds. While the ultimate goal for us, the main developers of GHC, is to produce research rather than code, we consider developing GHC to be an essential prerequisite: the artifacts of research are fed back into GHC, so that GHC can then be used as the basis for further research that builds on these previous ideas. Moreover, it is important that GHC is an industrial-strength product, since this gives greater credence to research results produced with it.
    [Show full text]