DOCSLIB.ORG

The Design, Implementation, and Evaluation of a Gradual Type System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Design, Implementation, and Evaluation of a Gradual Type System THEDESIGN,IMPLEMENTATION, ANDEVALUATIONOFAGRADUAL TYPESYSTEMFORDYNAMIC CLASSCOMPOSITION asumu takikawa Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy College of Computer and Information Science Northeastern University Boston, Massachusetts April 2016 Asumu Takikawa: The Design, Implementation, and Evaluation of a Gradual Type System for Dynamic Class Composition, Doctor of Philosophy, Northeastern University, Boston, Massachusetts © April 2016 ABSTRACTDynamically-typed programming languages are popular and widely- used, but their lack of static type guidance may hamper program maintenance. As a result, language designers have sought to augment dynamically-typed languages with static type-checking for several decades. Gradual typing has emerged at the forefront of these efforts, allowing programmers to add type annotations to existing untyped programs in a piecemeal fashion. These annotations are checked stat- ically and translated to dynamic checks at the boundaries between typed and untyped code to ensure sound interoperation. Despite the abundance of publications on gradual typing, several roadblocks still remain that prevent its adoption in practice. First, gradual type systems lack the expressivity to support the flexible object-oriented patterns, especially mixins expressed with first-class classes, that are used in dynamically-typed languages. Second, the dynamic checks that are installed for sound interoperation often slow down the program. Worse yet, no systematic evaluation method ex- ists for these gradual typing overheads. I present an expressive design of a gradual type system for object- oriented programming and introduce an effective method for the sys- tematic evaluation of its performance characteristics. v 謝辞 It has been a long and eventful six-year journey towards a PhD, and I ACKNOWLEDGMENTS/am deeply indebted to everyone who helped me along the way. Thank you to Kris De Volder and Gregor Kiczales at UBC for first exposing me to Racket (PLT Scheme at the time), and thus setting me on the path to Northeastern University. Thank you very much to Matthias Felleisen, who has been an ex- cellent advisor through and through. Even before I formally joined the program, Matthias had already started advising me1. Under his tutelage, I have grown substantially as a writer, programmer, and re- searcher. I cannot overstate my gratitude for his mentorship. I wish to thank Kathleen Fisher, Sam Tobin-Hochstadt, Jan Vitek, and Mitch Wand for serving on my thesis committee. Their advice has certainly improved this dissertation. In particular, I owe Sam a great deal for his help in learning the design and implementation of Typed Racket. Thanks to several grants from the National Science Foundation for funding my PhD education. This document would not have been possible without the help of my many wonderful co-authors. Many thanks to Earl Dean, Chris- tos Dimoulas, Dan Feltey, Robby Findler, Matthew Flatt, Ben Green- man, Max New, and Stevie Strickland. I also wish to thank my past and present partners in crime in PLT: Claire Alvis, Leif Andersen, Eli Barzilay, Sam Caldwell, Stephen Chang, Ryan Culpepper, Eric Dobson, Carl Eastlund, Spencer Florence, Tony Garnock-Jones, Phúc Nguyên,˜ Vincent St-Amour, and David Van Horn. I was aided by the members of the Programming Research Lab who have been great friends, colleagues, and mentors over the years. My heartfelt thanks to Amal Ahmed, William Bowman, Dan Brown, Ben Chung, Andrew Cobb, Jose Falcon, Oli Flückiger, Dee Glaze, Ben Lerner, Brian LaChance, Paley Li, Alex Marquez, Phillip Mates, Jamie Perconti, Hari Prashanth, Joe Sackett, Jonathan Schuster, Erik Silkensen, Gabriel Scherer, Justin Slepak, Paul Stansifer, Jesse Tov, Aaron Turon, and Dimitris Vardoulakis. I am eternally grateful to my partner Katrina Yupangco, who has kept me grounded and has inspired me to grow as a person. 最後に、本論文を書き終えるまで長年支えてきてくださった両親と兄 弟に深く感謝申し上げます。本当にありがとうございました。 ２０１６年４月 瀧川明日夢 1 Though I was not quite able to read the ninety papers he requested. vii CONTENTSi 1 1 3 1.practical1 A Brief gradual History of typing the Relationship Between Typed and introductionUntyped Languages 4 1.2 A Short History of Gradual Typing 6 1.3 Thesis 6 1.4 Approach 8 1.5 The Structure of this Thesis 8 ii 11 2 13 2.a1 designProgramming & model with for First-Class first-class Classes classes13 design2.1. by1 exampleA First Design for Typed First-Class Classes 15 2.1.2 Protecting Typed Code from Untyped Code 18 2.1.3 Same-component restrictions for method invo- cation 23 3 27 3.1 Formalizing Typed First-Class Classes 27 the model3.1.1 Syntax 27 3.1.2 Type System 33 3.1.3 Operational Semantics 36 3.1.4 An Example Reduction Sequence 39 3.2 Type Soundness for Mixed Programs 45 3.2.1 Type soundness 45 3.2.2 Complete monitoring 46 3.2.3 The Blame Theorem 50 4 53 4.1 By Principle 53 4scaling.2 Examples the design from Case Studies 56 4.3 Implementation challenges 62 4.3.1 Macrology 62 4.3.2 Types to contracts 64 4.4 Limitations 65 iii 69 5 73 5.evaluating1 Cases gradual73 typing 5effectiveness.2 The Process evaluation74 5.3 Quantitative Results 74 5.4 Qualitative Results 76 5.5 Problems and Fixes 77 ix 5.6 Discussion 78 6 79 6.1 Methodology 79 6formative.2 Results performance and Preliminary evaluation Interpretation 80 6.3 Problems and Fixes 83 6.3.1 A Soundness Bug 85 6.4 Threats to Validity 86 7 87 7.1 Evaluation Method 87 summative7.1.1 performanceBenchmarking Software evaluation Evolution 87 7.2 The Benchmark Programs 90 7.2.1 Overview 90 7.2.2 Adaptor Modules 94 7.2.3 Program Descriptions 95 7.3 Evaluating Typed Racket 97 7.3.1 Suffixtree in Depth 97 7.3.2 Reading the Figures 100 7.3.3 Interpretation 103 7.4 Quo Vadis Sound Gradual Typing? 105 7.4.1 Threats to Validity 106 7.4.2 What are the Bottlenecks? 107 7.5 Long Live Sound Gradual Typing 110 iv 111 8 113 8.related1 Other work Approaches to Interoperation 113 8related.2 Type work Systems for Object-Oriented Programming 114 8.3 Sealing and Polymorphic Contracts 115 8.4 Implementations & Evaluations of Gradual Typing 115 8.4.1 Gradualtalk 115 8.4.2 Reticulated Python 116 8.4.3 Thorn and StrongScript 117 8.4.4 Safe TypeScript and StrongScript 118 8.4.5 Evaluations of Optional Typing 119 v 121 9 123 9.final1 Future remarks Directions 124 conclusion9.1.1 Typed Racket with Object-Oriented Programming 124 9.1.2 Performance of Gradual Type Systems 125 vi 127 a 129 Bibliographyappendix 153 appendix x xi Part I PRACTICALGRADUALTYPING As scripts grow into full-fledged applications, programmers should want to port portions of their programs from scripting languages to languages with sound and rich type systems. – Tobin-Hochstadt and Felleisen (2006) 1 ProgrammingINTRODUCTION language designers have created dynamically-typed languages for over five decades. For the past twenty years, work- ing programmers have flocked to dynamically-typed programming languages such as Ruby, Python, and JavaScript. In response to this The reasons for the trend, language designers have pursued the incremental augmenta- popularity of tion of such languages with static type annotations. The unifying dynamically-typed languages are out of goal of this effort is to mitigate the drawbacks of dynamic types—the scope for this increased cost of documentation, maintenance, and refactoring pro- dissertation. cesses due to the lack of static types—without giving up the allure of dynamic typing. These efforts have culminated in two schools of thought: gradual type systems and optional type systems. Implementations of both kinds allow a programmer to add type annotations to an existing untyped code base. After adding such annotations, the resulting code base may contain both typed and untyped code. Where the two schools of thought differ is in whether and how these annotations are enforced and the guarantees that they provide. A gradual type system allows sound interaction between the typed and untyped portions of the program. At the interfaces between these typed and untyped fragments, the programmer writes down type an- notations. In order to ensure sound interoperation, the language must make sure that even untyped fragments uphold the type interfaces. To this end, gradual type systems translate the types at the interfaces into dynamic checks. There is an abundance of theoretical work in gradual type sys- tems (Ina and Igarashi 2011; Siek and Taha 2006, 2007; Takikawa et al. 2012; Tobin-Hochstadt and Felleisen 2006; Wolff et al. 2011), and several burgeoning research implementations have appeared: Typed Racket (Tobin-Hochstadt and Felleisen 2008), Gradualtalk (Allende et al. 2013), Reticulated Python (Vitousek et al. 2014), Safe TypeScript (Ras- togi et al. 2015), and most recently StrongScript (Richards et al. 2015). Meanwhile, an optional type system (Bracha 2004) does not guar- antee sound interoperation. The type system catches type errors in typed portions, but such errors in untyped portions are not checked either statically or dynamically. Instead, the programmer depends on the runtime system of the language to catch all remaining errors. This style of interoperation has been adopted by several industry projects such as Strongtalk (Bracha and Griswold 1993), Hack for PHP,1 MyPy 1 See hacklang.org and Verlaguet, Commercial Users of Functional Programming, Boston, MA 2013. 3 for Python,2 TypeScript,3 and Flow for JavaScript4. Additionally, sev- eral optional type systems have been presented in the academic lit- erature, such as optional typing for Clojure (Bonnaire-Sergeant 2012; Bonnaire-Sergeant et al. 2016) and for Lua (Maidl et al. 2014). This dissertation focuses on sound gradual typing instead of op- tional typing. The rationale for this focus is that as an academic work, this dissertation has the opportunity to tackle the more principled version of the problem of adding type annotations to an untyped lan- guage.
Load more

Recommended publications
  • Proceedings of the 8Th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (Ed.) Sponsors
    Proceedings of the 8th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (ed.) Sponsors We gratefully acknowledge the support given to the 8th European Lisp Symposium by the following sponsors: WWWLISPWORKSCOM i Organization Programme Committee Julian Padget – University of Bath, UK (chair) Giuseppe Attardi — University of Pisa, Italy Sacha Chua — Toronto, Canada Stephen Eglen — University of Cambridge, UK Marc Feeley — University of Montreal, Canada Matthew Flatt — University of Utah, USA Rainer Joswig — Hamburg, Germany Nick Levine — RavenPack, Spain Henry Lieberman — MIT, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Robert Strandh — University of Bordeaux, France Edmund Weitz — University of Applied Sciences, Hamburg, Germany Local Organization Christophe Rhodes – Goldsmiths, University of London, UK (chair) Richard Lewis – Goldsmiths, University of London, UK Shivi Hotwani – Goldsmiths, University of London, UK Didier Verna – EPITA Research and Development Laboratory, France ii Contents Acknowledgments i Messages from the chairs v Invited contributions Quicklisp: On Beyond Beta 2 Zach Beane µKanren: Running the Little Things Backwards 3 Bodil Stokke Escaping the Heap 4 Ahmon Dancy Unwanted Memory Retention 5 Martin Cracauer Peer-reviewed papers Efficient Applicative Programming Environments for Computer Vision Applications 7 Benjamin Seppke and Leonie Dreschler-Fischer Keyboard? How quaint. Visual Dataflow Implemented in Lisp 15 Donald Fisk P2R: Implementation of
    [Show full text]
  • A Python Implementation for Racket
    PyonR: A Python Implementation for Racket Pedro Alexandre Henriques Palma Ramos Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering Supervisor: António Paulo Teles de Menezes Correia Leitão Examination Committee Chairperson: Prof. Dr. José Manuel da Costa Alves Marques Supervisor: Prof. Dr. António Paulo Teles de Menezes Correia Leitão Member of the Committee: Prof. Dr. João Coelho Garcia October 2014 ii Agradecimentos Agradec¸o... Em primeiro lugar ao Prof. Antonio´ Leitao,˜ por me ter dado a oportunidade de participar no projecto Rosetta com esta tese de mestrado, por todos os sabios´ conselhos e pelos momentos de discussao˜ e elucidac¸ao˜ que se proporcionaram ao longo deste trabalho. Aos meus pais excepcionais e a` minha mana preferida, por me terem aturado e suportado ao longo destes quase 23 anos e sobretudo pelo incondicional apoio durante estes 5 anos de formac¸ao˜ superior. Ao pessoal do Grupo de Arquitectura e Computac¸ao˜ (Hugo Correia, Sara Proenc¸a, Francisco Freire, Pedro Alfaiate, Bruno Ferreira, Guilherme Ferreira, Inesˆ Caetano e Carmo Cardoso), por todas as sug- estoes˜ e pelo inestimavel´ feedback em artigos e apresentac¸oes.˜ Aos amigos em Tomar (Rodrigo Carrao,˜ Hugo Matos, Andre´ Marques e Rui Santos) e em Lisboa (Diogo da Silva, Nuno Silva, Pedro Engana, Kaguedes, Clara Paiva e Odemira), por terem estado pre- sentes, duma forma ou doutra, nos essenciais momentos de lazer. A` Fundac¸ao˜ para a Cienciaˆ e Tecnologia (FCT) e ao INESC-ID pelo financiamento e acolhimento atraves´ da atribuic¸ao˜ de uma bolsa de investigac¸ao˜ no ambitoˆ dos contratos Pest-OE/EEI/LA0021/2013 e PTDC/ATP-AQI/5224/2012.
    [Show full text]
  • Introduction to the Literature on Programming Language Design Gary T
    Computer Science Technical Reports Computer Science 7-1999 Introduction to the Literature On Programming Language Design Gary T. Leavens Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons Recommended Citation Leavens, Gary T., "Introduction to the Literature On Programming Language Design" (1999). Computer Science Technical Reports. 59. http://lib.dr.iastate.edu/cs_techreports/59 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Introduction to the Literature On Programming Language Design Abstract This is an introduction to the literature on programming language design and related topics. It is intended to cite the most important work, and to provide a place for students to start a literature search. Keywords programming languages, semantics, type systems, polymorphism, type theory, data abstraction, functional programming, object-oriented programming, logic programming, declarative programming, parallel and distributed programming languages Disciplines Programming Languages and Compilers This article is available at Iowa State University Digital Repository: http://lib.dr.iastate.edu/cs_techreports/59 Intro duction to the Literature On Programming Language Design Gary T. Leavens TR 93-01c Jan. 1993, revised Jan. 1994, Feb. 1996, and July 1999 Keywords: programming languages, semantics, typ e systems, p olymorphism, typ e theory, data abstrac- tion, functional programming, ob ject-oriented programming, logic programming, declarative programming, parallel and distributed programming languages.
    [Show full text]
  • The Racket Manifesto∗
    The Racket Manifesto∗ Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi Eli Barzilay, Jay McCarthy, Sam Tobin-Hochstadt Abstract The creation of a programming language calls for guiding principles that point the developers to goals. This article spells out the three basic principles behind the 20-year development of Racket. First, programming is about stating and solving problems, and this activity normally takes place in a context with its own language of discourse; good programmers ought to for- mulate this language as a programming language. Hence, Racket is a programming language for creating new programming languages. Second, by following this language-oriented approach to programming, systems become multi-lingual collections of interconnected components. Each language and component must be able to protect its specific invariants. In support, Racket offers protection mechanisms to implement a full language spectrum, from C-level bit manipulation to soundly typed extensions. Third, because Racket considers programming as problem solving in the correct language, Racket also turns extra-linguistic mechanisms into linguistic constructs, especially mechanisms for managing resources and projects. The paper explains these principles and how Racket lives up to them, presents the evaluation framework behind the design process, and concludes with a sketch of Racket’s imperfections and opportunities for future improvements. 1998 ACM Subject Classification D.3.3 Language Constructs and Features Keywords and phrases design
    [Show full text]
  • Comprehension First: Evaluating a Novel Pedagogy and Tutoring System for Program Tracing in CS1
    Session1: Novice Programmer ICER’17, August 18–20, 2017, Tacoma, WA, USA Comprehension First: Evaluating a Novel Pedagogy and Tutoring System for Program Tracing in CS1 Greg L. Nelson Benjamin Xie Andrew J. Ko University of Washington University of Washington University of Washington Allen School, DUB Group e Information School, DUB Group e Information School, DUB Group Seale, Washington 98195 Seale, Washington 98195 Seale, Washington 98195 [email protected] [email protected] [email protected] ABSTRACT building writing [17, 39, 68] and visualization tools [29, 34, 34, What knowledge does learning programming require? Prior work 57, 81, 87, 91]. Pedagogy has also evolved, reordering [23, 61, 80, has focused on theorizing program writing and problem solving 84, 85] and changing what is taught [14, 50, 72], rening worked skills. We examine program comprehension and propose a formal examples [58], explicitly teaching problem solving [48, 61] and theory of program tracing knowledge based on control ow paths program design [27], and exploring a discovery pedagogy [46]. through an interpreter program’s source code. Because novices Most of these diverse approaches have been evaluated in a writ- cannot understand the interpreter’s programming language nota- ing-focused pedagogical context. People receive instruction on a tion, we transform it into causal relationships from code tokens to programming construct’s syntax and semantics, practice by writing instructions to machine state changes. To teach this knowledge, code, then advance to the next construct (roughly a spiral syn- we propose a comprehension-rst pedagogy based on causal infer- tax approach [76]). In contrast, lile prior work has explored a ence, by showing, explaining, and assessing each path by stepping comprehension-rst pedagogy, teaching program semantics—how through concrete examples within many example programs.
    [Show full text]
  • I Throw Itching Powder at Tulips
    I Throw Itching Powder at Tulips Richard P. Gabriel IBM Research [email protected] Abstract program. But it also works for physical devices, biological systems, and people too. For example, when we teach a child Programming comes in many shapes & sizes. to add, we are creating a program that builds on the child’s Categories and Subject Descriptors D.2.9 [Software process existing ability to count on fingers. To the child the notion models] of adding is novel, but perhaps counting on fingers is not. At first, addition is a program; later it is an ability. General Terms Experimentation When we describe how to drive from one place to another, Keywords Agile; science; programming; natural language that’s a program that uses the driver’s ability to understand generation directions, to drive, and to recognize telltales to get that per- t son from one place to another. When people try to put together large software systems— I want to remind you of something simple: Programming large enough that teams are needed and dangerous enough and software engineering are not the same things. Neither that safety is crucial—they apply engineering techniques (as is programming the same as algorithm design. We’ve tan- best they can) to the project. That’s the start of software -en gled the several notions of programming—if we try we can gineering. When people wonder whether the program they unweave them, but sometimes we push on too quickly / get have devised really will achieve its desired purpose using the confused. William Griswold ventured this definition of soft- underlying mechanisms of the “computer,” that’s the start of ware engineering: the theory of computation and algorithm design.
    [Show full text]
  • Design of a Simple Functional Programming Language and Environment for CS2
    Design of a Simple Functional Programming Language and Environment for CS2 Brian T. Howard Department of Computer Science, DePauw University Abstract There are several advantages to introducing a functional language early in a student's college experience: it provides an excellent setting in which to explore recursively-defined functions and data structures, it encourages more abstract thinking, and it exposes students to a language paradigm that is likely quite different from their previous experience. Even in a core curriculum based on a traditional imperative (and object-oriented) language, it is valuable to spend two or three weeks investigating a functional language. However, we have found that most existing functional languages and environments pose significant hurdles to the introductory student, especially when the language is only being used for a short time. This paper discusses some of our ideas to simplify the framework, and allow students to experiment easily with the important concepts of functional programming in the setting of CS2. 1 Motivation There have been many proposals over the years to incorporate functional languages into the intro- ductory computer science curriculum, dating back at least to the mid-1980's with Abelson and Suss- man's influential text, Structure and Interpretation of Computer Programs [1]. They advocated the use of the Scheme dialect of Lisp because of its simple syntax and support for powerful abstraction mechanisms. Some more recent course designs [2, 3, 10] have also used Scheme, while others have used statically-typed languages such as Miranda, Haskell, or Standard ML [4, 6, 13, 15, 17, 18]. In each case, the reasons given for choosing a functional language include the support for abstractions (including recursion and higher-order functions), the simple semantics (with few or no side-effects), and the exposure to a different language paradigm and problem-solving style.
    [Show full text]
  • Dissertation
    HOWTOGENERATEACTIONABLE ADVICEABOUTPERFORMANCE PROBLEMS Vincent St-Amour Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy College of Computer and Information Science Northeastern University Boston, Massachusetts April 2015 Vincent St-Amour: How to Generate Actionable Advice about Performance Problems, Doctor of Philosophy, Northeastern University, Boston, Massachusetts © April 2015 ABSTRACT Performance engineering is an important activity regardless of ap- plication domain, as critical for server software as for mobile appli- cations. This activity, however, demands advanced, specialized skills that require a significant time investment to acquire, and are therefore absent from most programmers’ toolboxes. My thesis is that tool support can make performance engineering both accessible and time-efficient for non-expert programmers. To support this claim, this dissertation introduces two novel families of performance tools that are designed specifically to provide actionable information to programmers: optimization coaches and feature-specific profilers. This dissertation presents blueprints for building tools in these families, and provides examples from tools that I have built. v ACKNOWLEDGMENTS I would like to thank first and foremost my advisor Matthias Felleisen, who has taught me most of what I know today about the craft of research, writing, and design. He is the best advisor and ally I could have wished for, and I am incredibly grateful for of all the help and guidance he has provided me over the years. This work would not have been possible without the help of my collaborators, with whom I have worked on the projects described in these pages and others along the way: Leif Andersen, Eric Dob- son, Matthias Felleisen, Robby Findler, Matthew Flatt, Shu-yu Guo, Asumu Takikawa, Sam Tobin-Hochstadt, and Neil Toronto.
    [Show full text]
  • Extensible Languages for Flexible and Principled Domain Abstraction
    Extensible Languages for Flexible and Principled Domain Abstraction Dissertation for the degree of Doctor of Natural Sciences Submitted by Sebastian Thore Erdweg, MSc born March 14, 1985 in Frankfurt/Main Department of Mathematics and Computer Science Philipps-Universität Marburg Referees: Prof. Dr. Klaus Ostermann Dr. Eelco Visser Prof. Dr. Ralf Lämmel Submitted November 28, 2012. Defended March 06, 2013. Marburg, 2013. Erdweg, Sebastian: Extensible Languages for Flexible and Principled Domain Abstraction Dissertation, Philipps-Universität Marburg (1180), 2013. Curriculum vitae 2007, Bachelor of Science, TU Darmstadt 2009, Master of Science, Aarhus University Cover photo by Tellerdreher Photography, 2012. Abstract Most programming languages are designed for general-purpose software deve- lopment in a one-size-fits-all fashion: They provide the same set of language features and constructs for all possible applications programmers ever may want to develop. As with shoes, the one-size-fits-all solution grants a good fit to few applications only. The trend toward domain-specific languages, model-driven development, and language-oriented programming counters general-purpose languages by promo- ting the use of domain abstractions that facilitate domain-specific language features and constructs tailored to certain application domains. In particular, domain abstraction avoids the need for encoding domain concepts with general- purpose language features and thus allows programmers to program at the same abstraction level as they think. Unfortunately, current approaches to domain abstraction cannot deliver on the promises of domain abstraction. On the one hand, approaches that target internal domain-specific languages lack flexibility regarding the syntax, static checking, and tool support of domain abstractions, which limits the level of actually achieved domain abstraction.
    [Show full text]
  • Learning to Program in a Constructionist Way Mattia Monga, Michael Lodi, Dario Malchiodi, Anna Morpurgo, Bernadette Spieler
    Learning to program in a constructionist way Mattia Monga, Michael Lodi, Dario Malchiodi, Anna Morpurgo, Bernadette Spieler To cite this version: Mattia Monga, Michael Lodi, Dario Malchiodi, Anna Morpurgo, Bernadette Spieler. Learning to program in a constructionist way. Proceedings of Constructionism 2018, Aug 2018, Vilnius, Lithuania. hal-01913065 HAL Id: hal-01913065 https://hal.inria.fr/hal-01913065 Submitted on 6 Nov 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Learning to program in a constructionist way Constructionism Working Group 6 Michael Lodi∗ Dario Malchiodi Bernadette Spieler Alma Mater Studiorum - Mattia Monga Technische Universität Graz Università di Bologna Anna Morpurgo Austria Italy [email protected] [email protected] [email protected] [email protected] [email protected] Università degli Studi di Milano Italy ABSTRACT skills, as is recognizing how a relatively low number of abstract Although programming is often seen as a key element of construc- patterns can be applied to a potentially infinite spectrum of specific tionist approaches, the research on learning to program through situations.Programming languages and environments can either a constructionist strategy is somewhat limited, mostly focusing help or distract novices, thus the choice is not neutral and their on how to bring the abstract and formal nature of programming characteristics should be analyzed carefully to foster a good learn- languages into “concrete” or even tangible objects, graspable even ing context.
    [Show full text]
  • 9 European Lisp Symposium
    Proceedings of the 9th European Lisp Symposium AGH University of Science and Technology, Kraków, Poland May 9 – 10, 2016 Irène Durand (ed.) ISBN-13: 978-2-9557474-0-7 Contents Preface v Message from the Programme Chair . vii Message from the Organizing Chair . viii Organization ix Programme Chair . xi Local Chair . xi Programme Committee . xi Organizing Committee . xi Sponsors . xii Invited Contributions xiii Program Proving with Coq – Pierre Castéran .........................1 Julia: to Lisp or Not to Lisp? – Stefan Karpinski .......................1 Lexical Closures and Complexity – Francis Sergeraert ...................2 Session I: Language design3 Refactoring Dynamic Languages Rafael Reia and António Menezes Leitão ..........................5 Type-Checking of Heterogeneous Sequences in Common Lisp Jim E. Newton, Akim Demaille and Didier Verna ..................... 13 A CLOS Protocol for Editor Buffers Robert Strandh ....................................... 21 Session II: Domain Specific Languages 29 Using Lisp Macro-Facilities for Transferable Statistical Tests Kay Hamacher ....................................... 31 A High-Performance Image Processing DSL for Heterogeneous Architectures Kai Selgrad, Alexander Lier, Jan Dörntlein, Oliver Reiche and Marc Stamminger .... 39 Session III: Implementation 47 A modern implementation of the LOOP macro Robert Strandh ....................................... 49 Source-to-Source Compilation via Submodules Tero Hasu and Matthew Flatt ............................... 57 Extending Software Transactional
    [Show full text]
  • A New High School Curriculum Using Codeworld Fernando Alegre John Underwoood Gordon A
    Paper Session: Computational Thinking B SIGCSE ’20, March 11–14, 2020, Portland, OR, USA Introduction to Computational Thinking: A New High School Curriculum using CodeWorld Fernando Alegre John Underwoood Gordon A. Cain Center for STEM Literacy School of Education Louisiana State University Louisiana State University Baton Rouge, LA, USA Baton Rouge, LA, USA Juana Moreno Mario Alegre Department of Physics & Astronomy and Department of Physics Center for Computation & Technology Pennsylvania State University Louisiana State University University Park, PA, USA Baton Rouge, LA, USA ABSTRACT ACM Reference Format: The Louisiana Department of Education partnered with the Gordon Fernando Alegre, John Underwoood, Juana Moreno, and Mario Alegre. 2020. A. Cain Center at LSU to pilot a Computing High School Gradu- Introduction to Computational Thinking: A New High School Curriculum using CodeWorld. In ation Pathway. The frst course in the pathway, Introduction to The 51st ACM Technical Symposium on Computer Science Education (SIGCSE ’20), March 11–14, 2020, Portland, OR, USA. ACM, New Computational Thinking (ICT), is designed to teach programming York, NY, USA, 7 pages. https://doi.org/10.1145/3328778.3366960 and reinforce mathematical practice skills of nine-grade students, with an emphasis on promoting higher order thinking. In 2017- 18, about 200 students and fve teachers participated in the pilot, 1 INTRODUCTION in 2018-2019 the participation increased to 400 students, and in Our project started in 2015, when we were contacted by the East Ba- the current 2019-2020 year about 800 students in 11 schools are ton Rouge Parish School System (EBRPSS) to help develop computer involved. After describing the course content and the teacher train- science curricula for a new STEM magnet high school, to ofer new ing, we briefy discuss the data we have collected in the last two opportunities to the under-served population of the district, which years.
    [Show full text]