DOCSLIB.ORG

Revised5.92Report on the Algorithmic Language Scheme

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Revised5.92Report on the Algorithmic Language Scheme . Revised5 92 Report on the Algorithmic Language Scheme MICHAEL SPERBER WILLIAM CLINGER, R. KENT DYBVIG, MATTHEW FLATT, ANTON VAN STRAATEN (Editors) RICHARD KELSEY, JONATHAN REES (Editors, Revised5 Report on the Algorithmic Language Scheme) ROBERT BRUCE FINDLER, JACOB MATTHEWS (Authors, formal semantics) 18 January 2007 SUMMARY The report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including imperative, functional, and message passing styles, find convenient expression in Scheme. The introduction offers a brief history of the language and of the report. It also gives a short introduction to the basic concepts of the language. Chapter 2 explains Scheme’s number types. Chapter 3 defines the read syntax of Scheme programs. Chapter 4 presents the fundamental semantic ideas of the language. Chapter 5 defines notational conventions used in the rest of the report. Chapters 6 and 7 describe libraries and top-level programs, the basic organizational units of Scheme programs. Chapter 8 explains the expansion process for Scheme code. Chapter 9 explains the Scheme base library which contains the fundamental forms useful to programmers. Appendix 10 provides a formal semantics for a core of Scheme. Appendix A contains definitions for some of the derived forms described in the report. The report concludes with a list of references and an alphabetic index. This report is accompanied by a report describing standard libraries [40]; references to this document are identified by designations such as “library section” or “library chapter”. *** DRAFT*** This is a preliminary draft. It is intended to reflect the decisions taken by the editors’ committee, but contains many mistakes, ambiguities and inconsistencies. 2 Revised5.92 Scheme CONTENTS 9 Baselibrary ..................... 30 Introduction ...................... 3 9.1 Basetypes................... 30 9.2 Definitions................... 30 Description of the language 9.3 Syntax definitions . 31 1 OverviewofScheme................. 6 9.4 Bodiesandsequences. 31 1.1 Basictypes .................. 6 9.5 Expressions . 31 1.2 Expressions .................. 7 9.6 Equivalence predicates . 36 1.3 Variables and binding . 7 9.7 Procedure predicate . 39 1.4 Definitions................... 7 9.8 Unspecified value . 39 1.5 Procedures .................. 8 9.9 Generic arithmetic . 39 1.6 Procedure calls and syntactic keywords . 8 9.10Booleans.................... 46 1.7 Assignment .................. 8 9.11 Pairs and lists . 46 1.8 Derived forms and macros . 9 9.12Symbols .................... 49 1.9 Syntactic datums and datum values . 9 9.13 Characters. 49 1.10Libraries.................... 9 9.14Strings..................... 50 1.11 Top-level programs . 9 9.15Vectors .................... 51 2 Numbers....................... 10 9.16 Errors and violations . 52 2.1 Numericaltypes . 10 9.17 Controlfeatures. 52 2.2 Exactness ................... 10 9.18 Iteration.................... 54 2.3 Implementation restrictions . 10 9.19 Quasiquotation . 55 2.4 Infinities and NaNs . 11 9.20 Binding constructs for syntactic keywords . 56 3 Lexical syntax and read syntax . 11 9.21 Macro transformers . 57 3.1 Notation.................... 11 9.22 Tail calls and tail contexts . 59 3.2 Lexicalsyntax. 12 3.3 Readsyntax.................. 16 Formal Semantics 4 Semanticconcepts. 17 10 Formal semantics . 61 4.1 Programs and libraries . 17 10.1 Grammar . 61 4.2 Variables, syntactic keywords, and regions . 17 10.2Quote ..................... 64 4.3 Exceptional situations . 18 10.3 Multiple Values . 64 4.4 Argument checking . 18 10.4Exceptions .................. 64 4.5 Safety ..................... 18 10.5 Arithmetic & Basic Forms . 66 4.6 Booleanvalues ....... ....... .. 19 10.6Pairs&Eqv.................. 67 4.7 Multiple return values . 19 10.7 Procedures & Application . 68 4.8 Storagemodel. ....... ....... .. 19 10.8 Call/cc and Dynamic Wind . 71 4.9 Proper tail recursion . 19 10.9 Library Top Level . 71 5 Notation and terminology . 20 10.10Underspecification . 72 5.1 Requirement levels . 20 Appendices 5.2 Entryformat ................. 20 A Sample definitions for derived forms . 74 5.3 Evaluation examples . 21 B Additional material . 75 5.4 Unspecified behavior . 21 CExample ....................... 75 5.5 Exceptional situations . 22 References........................ 77 5.6 Naming conventions . 22 Alphabetic index of definitions of concepts, key- 5.7 Syntax violations . 22 words, and procedures . 80 6 Libraries ....................... 22 6.1 Library form . 23 6.2 Import and export levels . 25 6.3 Primitive syntax . 26 6.4 Examples ................... 27 7 Top-level programs . 28 7.1 Top-level program syntax . 28 7.2 Top-level program semantics . 28 8 Expansionprocess. 29 Introduction 3 INTRODUCTION Programming languages should be designed not by piling As Scheme became more widespread, local dialects be- feature on top of feature, but by removing the weaknesses gan to diverge until students and researchers occasion- and restrictions that make additional features appear nec- ally found it difficult to understand code written at other essary. Scheme demonstrates that a very small number of sites. Fifteen representatives of the major implementa- rules for forming expressions, with no restrictions on how tions of Scheme therefore met in October 1984 to work they are composed, suffice to form a practical and efficient toward a better and more widely accepted standard for programming language that is flexible enough to support Scheme. Participating in this workshop were Hal Abel- most of the major programming paradigms in use today. son, Norman Adams, David Bartley, Gary Brooks, William Clinger, Daniel Friedman, Robert Halstead, Chris Han- Scheme was one of the first programming languages to in- son, Christopher Haynes, Eugene Kohlbecker, Don Oxley, corporate first class procedures as in the lambda calculus, Jonathan Rees, Guillermo Rozas, Gerald Jay Sussman, and thereby proving the usefulness of static scope rules and Mitchell Wand. Kent Pitman made valuable contributions block structure in a dynamically typed language. Scheme to the agenda for the workshop but was unable to at- was the first major dialect of Lisp to distinguish proce- tend the sessions. Their report [7], edited by Will Clinger, dures from lambda expressions and symbols, to use a sin- was published at MIT and Indiana University in the sum- gle lexical environment for all variables, and to evaluate mer of 1985. Further revision took place in the spring the operator position of a procedure call in the same way of 1986 [9] (edited by Jonathan Rees and Will Clinger), as an operand position. By relying entirely on procedure and in the spring of 1988 [11] (also edited by Will Clinger calls to express iteration, Scheme emphasized the fact that and Jonathan Rees). Another revision published in 1998, tail-recursive procedure calls are essentially gotos that pass edited by Richard Kelsey, Will Clinger and Jonathan Rees, arguments. Scheme was the first widely used program- reflected further revisions agreed upon in a meeting at Xe- ming language to embrace first class escape procedures, rox PARC in June 1992 [26]. from which all previously known sequential control struc- tures can be synthesized. A subsequent version of Scheme Attendees of the Scheme Workshop in Pittsburgh in Octo- introduced the concept of exact and inexact numbers, an ber 2002 formed a Strategy Committee to discuss a process extension of Common Lisp’s generic arithmetic. More re- for producing new revisions of the report. The strategy cently, Scheme became the first programming language to committee drafted a charter for Scheme standardization. support hygienic macros, which permit the syntax of a This charter, together with a process for selecting edito- block-structured language to be extended in a consistent rial committees for producing new revisions for the report, and reliable manner. was confirmed by the attendees of the Scheme Workshop in Boston in November 2003. Subsequently, a Steering Com- Numerical computation was long neglected by the Lisp mittee according to the charter was selected, consisting of community. Until Common Lisp there was no carefully Alan Bawden, Guy L. Steele Jr., and Mitch Wand. An thought out strategy for organizing numerical computa- editors’ committee charged with producing this report was tion, and with the exception of the MacLisp system [35] also formed at the end of 2003, consisting of Will Clinger, little effort was made to execute numerical code efficiently. R. Kent Dybvig, Marc Feeley, Matthew Flatt, Richard The Scheme reports recognized the excellent work of the Kelsey, Manuel Serrano, and Mike Sperber, with Marc Fee- Common Lisp committee and accepted many of their rec- ley acting as Editor-in-Chief. Richard Kelsey resigned from ommendations, while simplifying and generalizing in some the committee in April 2005, and was replaced by Anton ways consistent with the purposes of Scheme. van Straaten. Marc Feeley and Manuel Serrano resigned from the committee in January 2006. Subsequently, the Background charter was revised to reduce the size of the editors’ com- mittee to five and to replace the office of Editor-in-Chief by The first description of Scheme was written by Gerald Jay a Chair and a Project
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]