DOCSLIB.ORG

The Bedrock Structured Programming System Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Bedrock Structured Programming System Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier The Bedrock Structured Programming System Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier Adam Chlipala MIT CSAIL [email protected] Abstract pend on. Examples include operating systems and runtime systems, We report on the design and implementation of an extensible pro- which today are almost exclusively written in C and its close rela- gramming language and its intrinsic support for formal verifica- tives. tion. Our language is targeted at low-level programming of infras- Need we always choose between performance and abstraction? tructure like operating systems and runtime systems. It is based on One approach to retaining both is metaprogramming, from basic a cross-platform core combining characteristics of assembly lan- cases of textual macro substitution as in the C preprocessor, to so- guages and compiler intermediate languages. From this founda- phisticated code generators like Yacc. Here we employ abstractions tion, we take literally the saying that C is a “macro assembly lan- that in a sense are compile-time only, running programs that gen- guage”: we introduce an expressive notion of certified low-level erate programs in C or other low-level languages. As a result, we macros, sufficient to build up the usual features of C and beyond incur no run-time cost to abstraction. as macros with no special support in the core. Furthermore, our Unfortunately, code generation is hard to get right. The C pre- macros have integrated support for strongest postcondition calcu- processor’s textual substitution mechanism allows for all sorts of lation and verification condition generation, so that we can provide scoping errors in macro definitions. There exist widely used alter- a high-productivity formal verification environment within Coq for natives, like the macro systems of Lisp/Scheme, OCaml (Camlp4), programs composed from any combination of macros. Our macro and Haskell (Template Haskell), which can enforce “hygiene” re- interface is expressive enough to support features that low-level quirements on lexical scoping in macro definitions. programs usually only access through external tools with no formal The functional programming community knows well the advan- guarantees, such as declarative parsing or SQL-inspired querying. tages of code generation with languages like Haskell and ML as The abstraction level of these macros only imposes a compile-time metalanguages for embedded domain-specific languages (DSLs). cost, via the execution of functional Coq programs that compute That is, one represents the programs of some object language, like programs in our intermediate language; but the run-time cost is C or CUDA, as data within the metalanguage, making it possible not substantially greater than for more conventional C code. We to compute programs of the object language at compile time using describe our experiences constructing a full C-like language stack all of the abstraction features of the metalanguage. using macros, with some experiments on the verifiability and per- There is a tower of static assurance levels for this kind of gener- formance of individual programs running on that stack. ative metaprogramming. Tools like Yacc receive little static assur- ance from their implementation languages, as they output source Categories and Subject Descriptors F.3.1 [Logics and meanings code as strings that the implementation language does not analyze. of programs]: Mechanical verification; D.3.4 [Programming Lan- Conventional macro systems, from primitive token substitution in guages]: Compilers C to hygienic Scheme macros, can provide stronger lexical guar- antees. Next in the tower are languages that allow for static typing Keywords generative metaprogramming; interactive proof assis- of macros, guaranteeing that any of their applications produce both tants; low-level programming languages; functional programming scope-safe and type-safe object-language code. Languages in this category include MetaML [30] and MacroML [13], for homoge- 1. Introduction neous metaprogramming where the meta and object languages are A fundamental tension in programming language design is between the same; and MetaHaskell [22], for heterogeneous metaprogram- performance and abstraction. Closer to the high-performance end ming where meta and object languages are different (e.g., Haskell of the spectrum, we have languages like C, which are often used and CUDA). Our contribution in this paper is to continue higher to implement low-level infrastructure that many applications de- up this tower of static guarantees: we support separate static check- ing of macros to guarantee that they always produce functionally correct object-language code. The programming language and associated verification tools Permission to make digital or hard copies of part or all of this work for personal or will need to provide a proof rule for each macro. A naive proof classroom use is granted without fee provided that copies are not made or distributed rule just expands macro applications using their definitions, pro- for profit or commercial advantage and that copies bear this notice and the full citation viding no abstraction benefit. We could ask instead that macro defi- on the first page. Copyrights for third-party components of this work must be honored. nitions include proof rules, and that the verification system requires For all other uses, contact the owner/author(s). programmers to prove that their macro definitions respect the as- ICFP ’13, September 25–27, 2013, Boston, MA, USA. Copyright is held by the owner/author(s). sociated proof rules. In effect, we have a macro system support- ACM 978-1-4503-2326-0/13/09. ing modularity in the style of well-designed functions, classes, or http://dx.doi.org/10.1145/2500365.2500592 libraries, with clear separation between implementation and inter- Constants c ::= [width-32 bitvectors] face. Code labels ` ::= ::: In this paper, we report on our experiences building such a Registers r ::= Sp j Rp j Rv macro system for a low-level language, intended as a replacement Addresses a ::= r j c j r + c for C in the systems programming domain. This macro system Lvalues L ::= r j [a]8 j [a]32 is part of the Bedrock library for the Coq proof assistant, which Rvalues R ::= L j c j ` provides an integrated environment for program implementation, Binops o ::= + j − j × specification, and verification. A prior publication [8] introduced Tests t ::= =j 6= j < j ≤ Bedrock’s support for proof automation, implementing example Instructions i ::= L R j L R o R programs using an earlier version of our macro system but not de- Jumps j ::= goto R j if (R t R) then ` else ` scribing it in detail. Since that paper was written, the macro system Specs S ::= ::: Blocks B ::= ` : fSg i∗; j has evolved, and we have used it to implement more interesting ∗ examples. We now present its design and implementation in detail, Modules M ::= B along with the higher-level language design principle that motivates it. Figure 1. Syntax of the Bedrock IL Our metalanguage is Gallina, the functional programming lan- guage in Coq’s logic. Our object language is a tiny compiler inter- mediate language. We build up the usual features of C via unpriv- prove correctness theorems within a framework for modular ver- ileged macros, and then we go further and implement features like ification, where we can verify libraries separately and then link declarative parsing and declarative querying of data structures as together their correctness theorems into whole-program correct- macros rather than ad-hoc external tools like Yacc and MySQL. ness theorems, without revisiting details of code implementation To support productive formal verification, we tag each macro or proof. This modularity holds even in the presence of a mutable with a proof rule. To be more precise, each macro contains a pred- heap that may hold callable code pointers, thanks to the XCAP [26] icate transformer, which evolves a logical assertion to reflect the program logic that sits at the base of our framework. effects of a program statement; and a verification condition gener- The remaining sections of this paper will walk through the steps ator, which outputs proof obligations associated with a use of the of building our stack of macros. We begin with a tiny assembly-like macro. These are some of the standard tools of highly automated language and proceed to introduce our notion of certified low-level program verification, and requiring them of all macros lets us build macros for it, build macros for basic C-like constructs, add support a generic verification environment that supports automated proofs for local variables and function calls, and culminate in the high- about programs built with macros drawn from diverse sources. We level macros for declarative parsing and querying. Next we evaluate call the central abstraction certified low-level macros. the effectiveness of our platform in terms of program verifiability and run-time performance, and we finish with a comparison to Our implementations and proofs have much in common with related work. compiler verification. For instance, CompCert [21] is a C com- Source code to both the Bedrock library and our example pro- piler implemented in Coq with a proof that it preserves program grams is available in the latest Bedrock source distribution at: semantics. Each of our macro implementations looks like one case of the CompCert compiler, dealing with a specific source language http://plv.csail.mit.edu/bedrock/ syntax construct, paired with the corresponding correctness proof cases. A specific program may draw upon several macros imple- mented by different programmers, who never considered how their 2. The Bedrock IL macros might interact. The proof approach from CompCert does The lowest layer of Bedrock is a simple intermediate language in- not extend straightforwardly to this setting, since each CompCert spired by common assembly languages. This Bedrock IL is easy subproof refers to one or more simulation relations between the to compile to those “real” languages, using only localized replace- programs of different fixed languages.
Load more

Recommended publications
  • Benjamin, Gesammelte Schriften, ,Mter Mitwirkung Von Theodor \\'1
    alter SELECTED WRITINGS VOLUME 1 1913-1926 Edited by Marcus Bullock and Michael W. Jennings THE BELKNAP PRESS OF HARVARD UNIVERSITY PRESS Cambridge, Massachusetts London, England , . I Contents Copyright © 1996 by the President and Fellows of Harvard College All rights rese rved Printed in the United States of America y l Second printing, 1997 METAPHYSICS OF "Experience" 3 This work is a transla tion of selec tions from Walter Benjamin, Gesammelte Schriften, ,mter Mitwirkung von Theodor \\'1. Adorno und Gershom Sch olem, heraltSgegeben von Rolf Tiedemann lind Hermann The Metaphysics of You Schweppenhiiuser, copyright © 1972, 1974, 1977, 1982, 1985, 1989 by Suh rkamp Verlag. "The Task of rhe Tra nslator" originally appeared in English in Wal ter Benjamin, Illuminations, ed ited by Hannah Two Poems by Friedrich Are nd t, English translation copyright © 1968 by Harcourt Brace Jovanovich, Inc. "On Language as Such The Life of Students 3' and the Language of Man," "Fate and Cha racter," "Critique of Violen,?;" " Nap les," and "One-Way Street" originally appeared in English in Walter Benjamin, Reflections, English translation copyright Aphorisms on Imaginati © 1978 by Harcoun Brace Jovanovich, Inc . Published by arrangement with Harc ourt Brace Jovanovich, Inc. "One-Way Street" also appeared i.n Walter Benjamin, "One-Way Street " and Other Writings (Lon­ A Child's View of ColOl don: NLBNerso, 1979, 1985). "Socrates" and "On the Program of the Coming Philosophy" originally appeared in English in The Philosophical Forum 15, nos. 1-2 (1983-1984). Socrates 52 Publication of this book has been aided by a grant from Inter Nationes, Bonn.
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • Structured Programming - Retrospect and Prospect Harlan D
    University of Tennessee, Knoxville Trace: Tennessee Research and Creative Exchange The aH rlan D. Mills Collection Science Alliance 11-1986 Structured Programming - Retrospect and Prospect Harlan D. Mills Follow this and additional works at: http://trace.tennessee.edu/utk_harlan Part of the Software Engineering Commons Recommended Citation Mills, Harlan D., "Structured Programming - Retrospect and Prospect" (1986). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/20 This Article is brought to you for free and open access by the Science Alliance at Trace: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The aH rlan D. Mills Collection by an authorized administrator of Trace: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. mJNDAMNTL9JNNEPTS IN SOFTWARE ENGINEERING Structured Programming. Retrospect and Prospect Harlan D. Mills, IBM Corp. Stnuctured program- 2 ' dsger W. Dijkstra's 1969 "Struc- mon wisdom that no sizable program Ste red .tured Programming" articlel could be error-free. After, many sizable ming haxs changed ho w precipitated a decade of intense programs have run a year or more with no programs are written focus on programming techniques that has errors detected. since its introduction fundamentally alteredhumanexpectations and achievements in software devel- Impact of structured programming. two decades ago. opment. These expectations and achievements are However, it still has a Before this decade of intense focus, pro- not universal because of the inertia of lot of potentialfor gramming was regarded as a private, industrial practices. But they are well- lot of fo puzzle-solving activity ofwriting computer enough established to herald fundamental more change.
    [Show full text]
  • INTRODUCTION to PL/1 PL/I Is a Structured Language to Develop Systems and Applications Programs (Both Business and Scientific)
    INTRODUCTION TO PL/1 PL/I is a structured language to develop systems and applications programs (both business and scientific). Significant features : v Allows Free format v Regards a program as a continuous stream of data v Supports subprogram and functions v Uses defaults 1 Created by Sanjay Sinha Building blocks of PL/I : v Made up of a series of subprograms and called Procedure v Program is structured into a MAIN program and subprograms. v Subprograms include subroutine and functions. Every PL/I program consists of : v At least one Procedure v Blocks v Group 2 Created by Sanjay Sinha v There must be one and only one MAIN procedure to every program, the MAIN procedure statement consists of : v Label v The statement ‘PROCEDURE OPTIONS (MAIN)’ v A semicolon to mark the end of the statement. Coding a Program : 1. Comment line(s) begins with /* and ends with */. Although comments may be embedded within a PL/I statements , but it is recommended to keep the embedded comments minimum. 3 Created by Sanjay Sinha 2. The first PL/I statement in the program is the PROCEDURE statement : AVERAGE : PROC[EDURE] OPTIONS(MAIN); AVERAGE -- it is the name of the program(label) and compulsory and marks the beginning of a program. OPTIONS(MAIN) -- compulsory for main programs and if not specified , then the program is a subroutine. A PL/I program is compiled by PL/I compiler and converted into the binary , Object program file for link editing . 4 Created by Sanjay Sinha Advantages of PL/I are : 1. Better integration of sets of programs covering several applications.
    [Show full text]
  • TITLE Kansas State Capitol Guide for Young People. Curriculum Packet for Teachers of Grades 4-7. INSTITUTION Kansas State Historical Society, Topeka.; Kansas State Dept
    DOCUMENT RESUME ED 477 746 SO 034 927 TITLE Kansas State Capitol Guide for Young People. Curriculum Packet for Teachers of Grades 4-7. INSTITUTION Kansas State Historical Society, Topeka.; Kansas State Dept. of Education, Topeka. PUB DATE 2002-00-00 NOTE 27p.; Prepared by the Education and Outreach Division. Intended to supplement the "Kansas State Capitol Guide for Young People." AVAILABLE FROM Kansas State Historical Society, 6425 S.W. 6th Avenue, Topeka, KS 66615. Tel: 785-272-8681; Fax: 785-272-8682; Web site: http://www.kshs.org/. For full text: http://www.kshs.org/teachers/ classroom/capitolguide.htm. PUB TYPE Guides Classroom Teacher (052) EDRS PRICE EDRS Price MF01/PCO2 Plus Postage. DESCRIPTORS Elementary Education; Guides; *Historic Sites; *Social Studies; *State Government; *State History IDENTIFIERS Indicators; *Kansas; *State Capitals ABSTRACT This curriculum packet is about the Kansas state capitol. The packet contains six graphic organizers for students to complete. The packets are divided into three sections (with their accompanying graphic organizers): (1) "Symbolism of the Kansas Capitol Dome Statue" (Who Are the Kansa?; Finding Your Way; Say It Again); (2) "Topping the Dome: Selecting a Symbol" (What Are They Saying?; What's on Top?); and (3)"Names as Symbols" (Native American Place Names). For each section, the teacher is provided with a main point and background information for the lesson. Answers for the graphic organizers, when necessary, are provided. (BT) Reproductions supplied by EDRS are the best that can be made from the original document. Guide for Your\g,Dori@ Ad Astra, the statue by Richard Bergen, was placed on the Capitol Cr) dome October 2002 CD Curriculum Packet O For Teachers of Grades 4-7 © 2002 Kansas State Historical Society Prepared in consultation with the KA.NSAS Kansas State Department of Education STATE HISTORICAL SOCIETY U.S.
    [Show full text]
  • Programming Language
    Programming language A programming language is a formal language, which comprises a set of instructions that produce various kinds of output. Programming languages are used in computer programming to implement algorithms. Most programming languages consist of instructions for computers. There are programmable machines that use a set of specific instructions, rather than general programming languages. Early ones preceded the invention of the digital computer, the first probably being the automatic flute player described in the 9th century by the brothers Musa in Baghdad, during the Islamic Golden Age.[1] Since the early 1800s, programs have been used to direct the behavior of machines such as Jacquard looms, music boxes and player pianos.[2] The programs for these The source code for a simple computer program written in theC machines (such as a player piano's scrolls) did not programming language. When compiled and run, it will give the output "Hello, world!". produce different behavior in response to different inputs or conditions. Thousands of different programming languages have been created, and more are being created every year. Many programming languages are written in an imperative form (i.e., as a sequence of operations to perform) while other languages use the declarative form (i.e. the desired result is specified, not how to achieve it). The description of a programming language is usually split into the two components ofsyntax (form) and semantics (meaning). Some languages are defined by a specification document (for example, theC programming language is specified by an ISO Standard) while other languages (such as Perl) have a dominant implementation that is treated as a reference.
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • Safe, Fast and Easy: Towards Scalable Scripting Languages
    Safe, Fast and Easy: Towards Scalable Scripting Languages by Pottayil Harisanker Menon A dissertation submitted to The Johns Hopkins University in conformity with the requirements for the degree of Doctor of Philosophy. Baltimore, Maryland Feb, 2017 ⃝c Pottayil Harisanker Menon 2017 All rights reserved Abstract Scripting languages are immensely popular in many domains. They are char- acterized by a number of features that make it easy to develop small applications quickly - flexible data structures, simple syntax and intuitive semantics. However they are less attractive at scale: scripting languages are harder to debug, difficult to refactor and suffers performance penalties. Many research projects have tackled the issue of safety and performance for existing scripting languages with mixed results: the considerable flexibility offered by their semantics also makes them significantly harder to analyze and optimize. Previous research from our lab has led to the design of a typed scripting language built specifically to be flexible without losing static analyzability. Inthis dissertation, we present a framework to exploit this analyzability, with the aim of producing a more efficient implementation Our approach centers around the concept of adaptive tags: specialized tags attached to values that represent how it is used in the current program. Our frame- work abstractly tracks the flow of deep structural types in the program, and thuscan ii ABSTRACT efficiently tag them at runtime. Adaptive tags allow us to tackle key issuesatthe heart of performance problems of scripting languages: the framework is capable of performing efficient dispatch in the presence of flexible structures. iii Acknowledgments At the very outset, I would like to express my gratitude and appreciation to my advisor Prof.
    [Show full text]
  • The Language of Fraud Cases. by Roger Shuy. New York: Oxford University Press, 2015
    1012 LANGUAGE, VOLUME 92, NUMBER 4 (2016) Jackendoff, Ray. 2002 . Foundations of language: Brain, meaning, grammar, evolution . Oxford: Oxford University Press. Newmeyer, Frederick J. 2005 . Possible and probable languages: A generative perspective on linguistic ty - pology . Oxford: Oxford University Press. Pinker, Steven, and Paul Bloom. 1990 . Natural language and natural selection. Behavioral and Brain Sci - ences 13.4.707–84. DOI: 10.1017/S0140525X00081061 . Progovac, Ljiljana . 1998a. Structure for coordination (part I). GLOT International 3.7.3–6. Progovac, Ljiljana . 1998b. Structure for coordination (part II). GLOT International 3.8.3–9. Department of Linguistics University of Washington–Seattle PO Box 352425 Seattle, WA 98195-2425 [[email protected]] The language of fraud cases. By Roger Shuy. New York: Oxford University Press, 2015. Pp. 301. ISBN 9780190270643. $99 (Hb). Reviewed by Lawrence M. Solan, Brooklyn Law School Most of Roger Shuy’s book , The language of fraud cases , describes cases in which S was in - volved as a linguistic expert, called by parties who were accused of some kind of fraud. Written in a journalistic style to engage readers from multiple disciplines, the book is a recent addition to a series of books that S has written over the past decade, describing his experiences as an expert witness. Other books in the series describe murder cases (2014) , bribery cases (2013), sexual mis - conduct cases (2012), perjury cases (2011), and defamation cases (2010). The case narratives most often describe a hypervigilant investigator or cooperating witness in - terpreting the target’s ambiguous or incomplete statements to confirm the suspicion that the target of the investigation has indeed committed a fraud.
    [Show full text]
  • A Block Design for Introductory Functional Programming in Haskell
    A Block Design for Introductory Functional Programming in Haskell Matthew Poole School of Computing University of Portsmouth, UK [email protected] Abstract—This paper describes the visual design of blocks for the learner, and to avoid syntax and type-based errors entirely editing code in the functional language Haskell. The aim of the through blocks-based program construction. proposed blocks-based environment is to support students’ initial steps in learning functional programming. Expression blocks and There exists some recent work in representing functional slots are shaped to ensure constructed code is both syntactically types within blocks-based environments. TypeBlocks [9] in- correct and preserves conventional use of whitespace. The design cludes three basic type connector shapes (for lists, tuples aims to help students learn Haskell’s sophisticated type system and functions) which can be combined in any way and to which is often regarded as challenging for novice functional any depth. The prototype blocks editor for Bootstrap [10], programmers. Types are represented using text, color and shape, [11] represents each of the five types of a simple functional and empty slots indicate valid argument types in order to ensure language using a different color, with a neutral color (gray) that constructed code is well-typed. used for polymorphic blocks; gray blocks change color once their type has been determined during program construction. I. INTRODUCTION Some functional features have also been added to Snap! [12] Blocks-based environments such as Scratch [1] and Snap! and to a modified version of App Inventor [13]. [2] offer several advantages over traditional text-based lan- This paper is structured as follows.
    [Show full text]
  • Dynamic Extension of Typed Functional Languages
    Dynamic Extension of Typed Functional Languages Don Stewart PhD Dissertation School of Computer Science and Engineering University of New South Wales 2010 Supervisor: Assoc. Prof. Manuel M. T. Chakravarty Co-supervisor: Dr. Gabriele Keller Abstract We present a solution to the problem of dynamic extension in statically typed functional languages with type erasure. The presented solution re- tains the benefits of static checking, including type safety, aggressive op- timizations, and native code compilation of components, while allowing extensibility of programs at runtime. Our approach is based on a framework for dynamic extension in a stat- ically typed setting, combining dynamic linking, runtime type checking, first class modules and code hot swapping. We show that this framework is sufficient to allow a broad class of dynamic extension capabilities in any statically typed functional language with type erasure semantics. Uniquely, we employ the full compile-time type system to perform run- time type checking of dynamic components, and emphasize the use of na- tive code extension to ensure that the performance benefits of static typing are retained in a dynamic environment. We also develop the concept of fully dynamic software architectures, where the static core is minimal and all code is hot swappable. Benefits of the approach include hot swappable code and sophisticated application extension via embedded domain specific languages. We instantiate the concepts of the framework via a full implementation in the Haskell programming language: providing rich mechanisms for dy- namic linking, loading, hot swapping, and runtime type checking in Haskell for the first time. We demonstrate the feasibility of this architecture through a number of novel applications: an extensible text editor; a plugin-based network chat bot; a simulator for polymer chemistry; and xmonad, an ex- tensible window manager.
    [Show full text]