DOCSLIB.ORG

Don't Mind the Formalization

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Don't Mind the Formalization DON’T MIND THE FORMALIZATION GAP: THE DESIGN AND USAGE OF HS-TO-COQ Antal Spector-Zabusky A DISSERTATION in Computer and Information Science Presented to the Faculties of the University of Pennsylvania in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy 2021 Supervisor of Dissertation Stephanie Weirich Professor of Computer and Information Science Graduate Group Chairperson Mayur Naik, Professor of Computer and Information Science Dissertation Commitee Steve Zdancewic, Professor of Computer and Information Science, Chair Benjamin Pierce, Professor of Computer and Information Science Mayur Naik, Professor of Computer and Information Science Andrew Appel, Professor of Computer Science, Princeton DON’T MIND THE FORMALIZATION GAP: THE DESIGN AND USAGE OF HS-TO-COQ COPYRIGHT 2021 Antal Spector-Zabusky This work is licensed under a Creative Commons Attribution-NonCommercial-Share- Alike 4.0 International (CC BY-NC-SA 4.0) License To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/4.0/ Acknowledgments First and foremost, I want to extend my deepest thanks to my advisor, Stephanie Weirich. I still remember being an uncertain PhD student coming into her office to change projects and hearing her say, “I have a great project for you”. I was nervous it wouldn’t be a good fit, but from the moment the next words were out of her mouth I knew it was perfect. She understood me from the get-go, both as a researcher and as a person, and the lessons I took from her mentorship in research, programming, theorem proving, and writing made me the programming language theorist I am today. Stephanie’s keen mind, her insightful problem-solving skills, her persistence, her eagerness to get hands on with code, and her patience made her the best advisor I could have asked for. And her passion for board games was crucially important icing on the cake! Without you, Stephanie, this document – and everything it stands for – wouldn’t be here. In a similar vein, I want to extend my thanks to Benjamin Pierce, with whom I worked when I first arrived at Penn. Benjamin knew how to get me involved with research, bringing me into collaborations both inside and outside Penn and ensuring my entry into the programming language research community; he also gave me my first graduate-level lessons in writing good research papers and giving high-quality talks, skills which I have taken to heart and have kept cultivating. Benjamin also helped me through my struggle to find a thesis project that suited me, and was dedicated to helping me find that project no matter who was running it. Thank you, Benjamin, for getting me started, and for knowing when to let me fly. I also want to thank the rest of my committee, for reading this dissertation and more. Thank you to Steve Zdancewic, who has been there since the beginning; beyond this thesis, he’s helped me with many a presentation and sparred with me in many a board game. Thank you to Andrew Appel, whose presence and advice as part of DeepSpec helped bring a different perspective to my research goals. And thank you to Mayur Naik for stepping into the DeepSpec world to understand my work. Beyond my committee, I have been supported by more people than I can name. Thank you to my Penn PL cohort, who entered the PhD with me: Leonidas Lam- propoulos, Jennifer Paykin, and Robert Rand. It was a sincere pleasure to navigate the PhD together with them, from classes to Quizzo to research and finally (finally!) to graduating. I’m glad to call them my colleagues, but I’m even more grateful to call them my friends. And thank you as well to Kenny Foner, Alex Burka, Sonia Roberts, and my other Penn friends for their academic, institutional, and personal support. In the same vein, my thanks go out to all my other collaborators, because research is not an island. Thank you to the hs-to-coq team, without whom the work in this dissertation wouldn’t have been possible: Stephanie, Yao Li, Joachim Breitner, iii Christine Rizkallah, and John Wiegley. Going back further, thank you to my earliest collaborators, on testing and micro-policies: Benjamin, Leo, Arthur Azevedo de Amorim, Cătălin Hriț, cu, John Hughes, Dimitrios Vytiniotis, Nick Giannarakis, and Andrew Tolmach. And of course, my thanks to everyone in Penn PL Club not just for their academic support, but also for making Fridays (and other days) better. Even before Penn, my thanks to the Williams CS department for nurturing me and my love of computer science. In particular, my thanks to my undergraduate advisor Steve Freund, for teaching me about programming language theory, introducing me to PL research, and for helping me navigate my path forward; and to Jeannie Albrecht, for giving me the opportunity to do my very first computer science research project. I also want to thank GET-UP for supporting all the graduate students at Penn. I’m proud of what we built in solidarity with each other, and although we didn’t win, I believe we can change that next time. On a less academic note, my thanks to the communities in Philadelphia who supported me throughout this process. Thank you to my Penn Quizzo team, for making sure I was out of the house on Monday nights; to Penn Gamers, for transmuting a shared love of board games into friendships; and to the Thursday night contra dance, for being a broad community that embraced me and kept me moving. I would not have made it to the finish line without the love and support of all my friends. My wholehearted thanks to the group chat: Colin Killick, Molly Olguín, Mattie Mitchell, Annie Moriondo, Jackie Pineda-Andrews, and Ian Pineda-Andrews (or Agni, Casimir, Ilaina, Max, Screech, and all of Punchworld —Zoltán). Thank you for being there literally 24/7. I appreciate their being a neverending fount of camaraderie, serious ideas, silly jokes, and sincere emotional support. My thanks to my Williams undergraduate thesis crew: Matt Hosek, Tori Borish, Katie Kumamoto, and Dan Kohane. I’m glad to have had them along for this journey twice – and we’re all finally allowed to sleep now! My thanks to Aaron Bauer, Jake Levinson, and Nick Arnosti, who introduced me to board games. This would be enough of a reason for thanks, but I also appreciate their lasting friendship and its propensity for deep conversation (preferably over a board game or four). And my thanks to Sasha Ehrhardt for being my friend since we were 5 years old, from tigers and gibbons to computers and libraries with a whole lot more in between. My thanks to Caron Bove for driving me between LACS and IHS back in high school so that I could attend my math and science classes – I told you then that I’d acknowledge you now, and I’m delighted to finally be able to do so. I want to recognize my great-uncle Clifford Spector, whom I wish I’d met. It amazes me that his work in computability theory nestled so closely next to my chosen field without me realizing it, and I’m tickled that he ended up my academic great- great-great-uncle, our familial and professional lineages off by only two generations. And last, but never least, my neverending thanks and gratitude to my family. Your love, support, and jokes (good and bad) mean more to me than I will ever be able to say. My thanks to my mom and dad, Stacia Zabusky and Donald Spector, for not merely believing in me, but for reifying that belief into actions that build me up. And my thanks to my brother, Elias Spector-Zabusky, for understanding me more deeply than anybody else in the world. I love you all. iv ABSTRACT DON’T MIND THE FORMALIZATION GAP: THE DESIGN AND USAGE OF HS-TO-COQ Antal Spector-Zabusky Stephanie Weirich Using proof assistants to perform formal, mechanical software verification is a powerful technique for producing correct software. However, the verification is time- consuming and limited to software written in the language of the proof assistant. As an approach to mitigating this tradeoff, this dissertation presents hs-to-coq, a tool for translating programs written in the Haskell programming language into the Coq proof assistant, along with its applications and a general methodology for using it to verify programs. By introducing edit files containing programmatic descriptions of code transformations, we provide the ability to flexibly adapt our verification goals to exist anywhere on the spectrum between “increased confidence” and “full functional correctness”. v Contents Title i Copyright ii Acknowledgments iii Abstractv Contents vi List of Figures viii Chapter 1. Introduction1 1.1. How to work with hs-to-coq 4 1.2. The edit language and the mechanized formalization gap8 1.3. DeepSpec9 1.4. Contributions 10 1.5. Outline 11 Chapter 2. An Introductory Example: Bags 12 2.1. Bags in GHC 12 2.2. Translating Bag and its operations 15 2.3. Edits for Bags 16 2.4. Specifying the behavior of Bags 18 2.5. From program to theorem 19 Chapter 3. hs-to-coq: Design and Usage 21 3.1. How we’ve used hs-to-coq 21 3.2. Desiderata 22 3.3. Test suite 25 3.4. Mechanized formalization gaps 26 3.5. Infix operators 26 3.6. Notation for literals 27 3.7. Transforming code automatically 29 3.8. Partiality 31 3.9. Recursion 33 Chapter 4. The Edit Language 39 4.1.
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]
  • Cambridge University Press 978-1-108-78987-5 — How to Write Good Programs Perdita Stevens Index More Information
    Cambridge University Press 978-1-108-78987-5 — How to Write Good Programs Perdita Stevens Index More Information Index A bold page number indicates where a term is deined. abstract syntax tree, 105 C, 35, 45, 189 abstraction, 29, 141 C♯,35 see also model C++, 35, 190 agile, 64, 159, 198 camel case, 89 algorithm, 29, 147, 148, 196 change, 141, 144, 197 Alice, 44 checklist, 127 arguments, 25,28 cloud, 66 functions as, 45 code order of, 108 commented-out, 62 type of, 41, 108 completion, 52,90 assert, 71 dead, 64 assignment, 131 line length, 99 vs. comparison, 126 reputable body of, 46, 63, 94, 99 Atom, 18 spaghetti, 98, 122 autocompletion, 52,90 unreachable, 64 autosave, 57 code sense, 3, 133 coding, 4 backups, 65 coding dojo, 153 bar, see metasyntactic variable coding interview, 148 BASIC, 44, 125 command line, 15, 49 baz, see metasyntactic variable comment, 27, 70, 85–88 BlueJ, 44, 54 commenting-out, 62 breakpoint, 111 comparison bug, 32, 101, 190, 191 of booleans, 126 after removing, 124 of objects, 130 avoiding, 138 vs. assignment, 126 avoiding recurrence of, 77 compiler, 13, 35 in compiler, 109 bug, 109 removing, 122 incremental, 51 the Lauren bug, 78 computational complexity, 148 see also debugging content assist, 52,90 build, 51, 53 contract, 88 202 © in this web service Cambridge University Press www.cambridge.org Cambridge University Press 978-1-108-78987-5 — How to Write Good Programs Perdita Stevens Index More Information Index 203 crash, 118 time, 146 currying, 23 user, 146 Emacs, 18, 49, 58, 90, 95 data science, 192 embedded
    [Show full text]
  • Section “Creating R Packages” in Writing R Extensions
    Writing R Extensions Version 3.1.0 Under development (2013-03-29) R Core Team Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the R Core Team. Copyright c 1999{2013 R Core Team i Table of Contents Acknowledgements ::::::::::::::::::::::::::::::::: 1 1 Creating R packages:::::::::::::::::::::::::::: 2 1.1 Package structure :::::::::::::::::::::::::::::::::::::::::::::: 3 1.1.1 The `DESCRIPTION' file :::::::::::::::::::::::::::::::::::: 4 1.1.2 Licensing:::::::::::::::::::::::::::::::::::::::::::::::::: 9 1.1.3 The `INDEX' file :::::::::::::::::::::::::::::::::::::::::: 10 1.1.4 Package subdirectories:::::::::::::::::::::::::::::::::::: 11 1.1.5 Data in packages ::::::::::::::::::::::::::::::::::::::::: 14 1.1.6 Non-R scripts in packages :::::::::::::::::::::::::::::::: 15 1.2 Configure and cleanup :::::::::::::::::::::::::::::::::::::::: 16 1.2.1 Using `Makevars'::::::::::::::::::::::::::::::::::::::::: 19 1.2.1.1 OpenMP support::::::::::::::::::::::::::::::::::::
    [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]
  • Section “Creating R Packages” in Writing R Extensions
    Writing R Extensions Version 3.0.0 RC (2013-03-28) R Core Team Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the R Core Team. Copyright c 1999{2013 R Core Team i Table of Contents Acknowledgements ::::::::::::::::::::::::::::::::: 1 1 Creating R packages:::::::::::::::::::::::::::: 2 1.1 Package structure :::::::::::::::::::::::::::::::::::::::::::::: 3 1.1.1 The `DESCRIPTION' file :::::::::::::::::::::::::::::::::::: 4 1.1.2 Licensing:::::::::::::::::::::::::::::::::::::::::::::::::: 9 1.1.3 The `INDEX' file :::::::::::::::::::::::::::::::::::::::::: 10 1.1.4 Package subdirectories:::::::::::::::::::::::::::::::::::: 11 1.1.5 Data in packages ::::::::::::::::::::::::::::::::::::::::: 14 1.1.6 Non-R scripts in packages :::::::::::::::::::::::::::::::: 15 1.2 Configure and cleanup :::::::::::::::::::::::::::::::::::::::: 16 1.2.1 Using `Makevars'::::::::::::::::::::::::::::::::::::::::: 19 1.2.1.1 OpenMP support:::::::::::::::::::::::::::::::::::: 22 1.2.1.2
    [Show full text]
  • Writing R Extensions
    Writing R Extensions Version 4.1.1 Patched (2021-09-22) R Core Team This manual is for R, version 4.1.1 Patched (2021-09-22). Copyright c 1999{2021 R Core Team Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into an- other language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the R Core Team. i Table of Contents Acknowledgements ::::::::::::::::::::::::::::::::::::::::::::::::: 1 1 Creating R packages ::::::::::::::::::::::::::::::::::::::::::: 2 1.1 Package structure :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 1.1.1 The DESCRIPTION file ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.1.2 Licensing ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 1.1.3 Package Dependencies::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 9 1.1.3.1 Suggested packages:::::::::::::::::::::::::::::::::::::::::::::::::::::: 12 1.1.4 The INDEX file ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 13 1.1.5 Package subdirectories :::::::::::::::::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Year of the Horse. the Months of The
    here are many animals named in the Template of the Hidden Texts which appear anomalous to the context. It turns out they are Chinese years or Celtic symbols (such as salmon) or constellations. Also there are several codes which the word HORSE indicates. The months of the horse,which happen to be the same horses as those of the "apocalypse" (the "unveiling"), the constellations: of the winged horse Scheat of Pegasus, the colt Equulus the foal, the horse's blaze Kurnah in Cepheus, Hippocampus the seahorse, Leucippe the white horse, Alpha Andromeda and then there is the Year of the Horse. The months of the horse have far too many ciphers ~ nag, Dan, ornament, Ma, ears, Be, Elm, shoe, Ara, Bau and all the other words which mean Gemini, Cancer, Virgo, Libra/October, Scorpio and Sagittarius. Something big is slotted for Sagittarius. The White Horse Warning at Uffington is Sagittarius, complete with the large cross of the bow and arrow. Sagittarius is not shown at all on the zodiac column of St John The Divine. This forum is a collection of all the lines with the word horse or fourteen coded within them. Before we get started on the year which is the beginning of the end for our current lifestyle, a pertinent detail will be outlined. The matter of the "shar" of the Nibiru system. The shar is the "year", the orbit this solar system keeps. Many people have many different numbers of our years in one shart. It seems the Anakim (the biblical spelling for a civilization who have as many names as there are tribes on Earth) do have some control over their system.
    [Show full text]
  • Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers
    Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers Jeremy Singer and Blair Archibald School of Computing Science University of Glasgow UK [email protected] [email protected] What kinds of mistakes are made by novice Haskell developers, as they learn about functional pro- gramming? Is it possible to analyze these errors in order to improve the pedagogy of Haskell? In 2016, we delivered a massive open online course which featured an interactive code evaluation en- vironment. We captured and analyzed 161K interactions from learners. We report typical novice developer behavior; for instance, the mean time spent on an interactive tutorial is around eight min- utes. Although our environment was restricted, we gain some understanding of Haskell novice er- rors. Parenthesis mismatches, lexical scoping errors and do block misunderstandings are common. Finally, we make recommendations about how such beginner code evaluation environments might be enhanced. 1 Introduction The Haskell programming language [14] has acquired a reputation for being difficult to learn. In his presentation on the origins of Haskell [23] Peyton Jones notes that, according to various programming language popularity metrics, Haskell is much more frequently discussed than it is used for software implementation. The xkcd comic series features a sarcastic strip on Haskell’s side-effect free property [21]. Haskell code is free from side-effects ‘because no-one will ever run it.’ In 2016, we ran the first instance of a massive open online course (MOOC) at Glasgow, providing an introduction to functional programming in Haskell. We received many items of learner feedback that indicated difficulty in learning Haskell.
    [Show full text]
  • Haskell As a Higher Order Structural Hardware Description Language
    Haskell as a higher order structural hardware description language Master's thesis by Matthijs Kooijman December 9, 2009 Committee: Dr. Ir. Jan Kuper Ir. Marco Gerards Ir. Bert Molenkamp Dr. Ir. Sabih Gerez Computer Architecture for Embedded Systems Faculty of EEMCS University of Twente Abstract Functional hardware description languages have been around for a while, but never saw adoption on a large scale. Even though advanced features like higher order functions and polymorphism could enable very natural parametrization of hardware descriptions, the conventional hardware description languages VHDL and Verilog are still most widely used. Cλash is a new functional hardware description language using Haskell's syntax and semantics. It allows structurally describing synchronous hardware, using normal Haskell syntax combined with a selection of built-in functions for operations like addition or list operations. More complex constructions like higher order functions and polymorphism are fully supported. Cλash supports stateful descriptions through explicit descriptions of a function's state. Every function accepts an argument containing its current state and returns its updated state as a part of its result. This means every function is called exactly once for each cycle, limiting Cλash to synchronous systems with a single clock domain. A prototype compiler for Cλash has been implemented that can generate an equivalent VHDL description (using mostly structural VHDL). The prototype uses the front-end (parser, type-checker, desugarer) ofthe existing GHC Haskell compiler. This front-end generates a Core version of the description, which is a very small typed functional language. A normalizing system of transformations brings this Core version into a normal form that has any complex parts (higher order functions, polymorphism, complex nested structures) removed.
    [Show full text]
  • A Proxima-Based Haskell IDE
    Thesis for the degree of Master of Science A Proxima-based Haskell IDE Gerbo Engels October 2008 INF/SCR-07-93 Supervisor: Center for Software Technology prof. dr. S. Doaitse Swierstra Dept. of Information and Computing Sciences Universiteit Utrecht Daily supervisor: Utrecht, The Netherlands dr. Martijn M. Schrage Abstract Proxima is a generic presentation-oriented editor for structured documents, in which a graphical presentation of the document can be edited directly (WYSIWYG editing), resulting in changes in the underlying structure of the document. Proxima understands the document structure and it supports direct edit operations on the document structure as well. A Proxima instantiation uses a parser to get the document structure; modern compilers have parsers as well, which may be accessible through an API. Using the parser of an external compiler as the Proxima parser saves one from writing a new parser. Furthermore, the parse tree of a com- piler can contain extra information that is useful to display in an editor, such as type information of a Haskell compiler in a Haskell source code editor. This thesis aims to use the parser of an external compiler as the Proxima parser. We identify and solve problems that arise when using the parser of an external compiler as the Proxima parser, and two Haskell editors are developed as Proxima instantiations that use the parser of GHC or EHC respectively. i ii Contents 1 Introduction 1 1.1 Thesis Overview.........................................2 I The State of the World3 2 Existing Haskell Editors and IDE’s5 2.1 Visual Haskell...........................................6 2.2 Eclipse Plug-in...........................................7 2.3 Haskell Editors Written in Haskell...............................8 2.4 Other Editors or Tools.....................................
    [Show full text]