DOCSLIB.ORG

MIT/GNU Scheme Reference Manual

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
MIT/GNU Scheme Reference Manual MIT/GNU Scheme Reference Manual for release 11.2 2020-06-16 by Chris Hanson the MIT Scheme Team and a cast of thousands This manual documents MIT/GNU Scheme 11.2. Copyright c 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Massachusetts Institute of Technology Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License." i Short Contents Acknowledgements :::::::::::::::::::::::::::::::::::::::: 1 1 Overview :::::::::::::::::::::::::::::::::::::::::::: 3 2 Special Forms:::::::::::::::::::::::::::::::::::::::: 15 3 Equivalence Predicates :::::::::::::::::::::::::::::::: 57 4 Numbers:::::::::::::::::::::::::::::::::::::::::::: 63 5 Characters :::::::::::::::::::::::::::::::::::::::::: 99 6 Strings :::::::::::::::::::::::::::::::::::::::::::: 107 7 Lists :::::::::::::::::::::::::::::::::::::::::::::: 129 8 Vectors :::::::::::::::::::::::::::::::::::::::::::: 147 9 Bit Strings ::::::::::::::::::::::::::::::::::::::::: 151 10 Miscellaneous Datatypes :::::::::::::::::::::::::::::: 155 11 Associations :::::::::::::::::::::::::::::::::::::::: 169 12 Procedures ::::::::::::::::::::::::::::::::::::::::: 203 13 Environments ::::::::::::::::::::::::::::::::::::::: 211 14 Input/Output::::::::::::::::::::::::::::::::::::::: 215 15 Operating-System Interface:::::::::::::::::::::::::::: 263 16 Error System ::::::::::::::::::::::::::::::::::::::: 297 17 Graphics ::::::::::::::::::::::::::::::::::::::::::: 321 18 Win32 Package Reference ::::::::::::::::::::::::::::: 335 19 Standards Support::::::::::::::::::::::::::::::::::: 345 A GNU Free Documentation License :::::::::::::::::::::: 359 B Binding Index :::::::::::::::::::::::::::::::::::::: 367 C Concept Index :::::::::::::::::::::::::::::::::::::: 389 iii Table of Contents Acknowledgements :::::::::::::::::::::::::::::::::: 1 1 Overview ::::::::::::::::::::::::::::::::::::::::: 3 1.1 Notational Conventions ::::::::::::::::::::::::::::::::::::::::: 4 1.1.1 Errors ::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.1.2 Examples :::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.1.3 Entry Format:::::::::::::::::::::::::::::::::::::::::::::: 5 1.2 Scheme Concepts ::::::::::::::::::::::::::::::::::::::::::::::: 6 1.2.1 Variable Bindings :::::::::::::::::::::::::::::::::::::::::: 6 1.2.2 Environment Concepts ::::::::::::::::::::::::::::::::::::: 6 1.2.3 Initial and Current Environments :::::::::::::::::::::::::: 7 1.2.4 Static Scoping ::::::::::::::::::::::::::::::::::::::::::::: 7 1.2.5 True and False::::::::::::::::::::::::::::::::::::::::::::: 8 1.2.6 External Representations :::::::::::::::::::::::::::::::::: 8 1.2.7 Disjointness of Types :::::::::::::::::::::::::::::::::::::: 9 1.2.8 Storage Model ::::::::::::::::::::::::::::::::::::::::::::: 9 1.3 Lexical Conventions :::::::::::::::::::::::::::::::::::::::::::: 9 1.3.1 Whitespace :::::::::::::::::::::::::::::::::::::::::::::::: 9 1.3.2 Delimiters :::::::::::::::::::::::::::::::::::::::::::::::: 10 1.3.3 Identifiers :::::::::::::::::::::::::::::::::::::::::::::::: 10 1.3.4 Uppercase and Lowercase ::::::::::::::::::::::::::::::::: 10 1.3.5 Naming Conventions:::::::::::::::::::::::::::::::::::::: 10 1.3.6 Comments:::::::::::::::::::::::::::::::::::::::::::::::: 11 1.3.7 Additional Notations ::::::::::::::::::::::::::::::::::::: 11 1.4 Expressions ::::::::::::::::::::::::::::::::::::::::::::::::::: 12 1.4.1 Literal Expressions ::::::::::::::::::::::::::::::::::::::: 13 1.4.2 Variable References ::::::::::::::::::::::::::::::::::::::: 13 1.4.3 Special Form Syntax :::::::::::::::::::::::::::::::::::::: 13 1.4.4 Procedure Call Syntax :::::::::::::::::::::::::::::::::::: 13 2 Special Forms :::::::::::::::::::::::::::::::::: 15 2.1 Lambda Expressions::::::::::::::::::::::::::::::::::::::::::: 15 2.2 Lexical Binding:::::::::::::::::::::::::::::::::::::::::::::::: 17 2.3 Dynamic Binding:::::::::::::::::::::::::::::::::::::::::::::: 20 2.3.1 Fluid-Let ::::::::::::::::::::::::::::::::::::::::::::::::: 22 2.4 Definitions :::::::::::::::::::::::::::::::::::::::::::::::::::: 22 2.4.1 Top-Level Definitions ::::::::::::::::::::::::::::::::::::: 23 2.4.2 Internal Definitions ::::::::::::::::::::::::::::::::::::::: 23 2.5 Assignments::::::::::::::::::::::::::::::::::::::::::::::::::: 24 2.6 Quoting ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 24 2.7 Conditionals::::::::::::::::::::::::::::::::::::::::::::::::::: 26 2.8 Sequencing :::::::::::::::::::::::::::::::::::::::::::::::::::: 28 iv MIT/GNU Scheme 11.2 2.9 Iteration :::::::::::::::::::::::::::::::::::::::::::::::::::::: 29 2.10 Structure Definitions ::::::::::::::::::::::::::::::::::::::::: 31 2.11 Macros ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 36 2.11.1 Binding Constructs for Syntactic Keywords :::::::::::::: 37 2.11.2 Pattern Language ::::::::::::::::::::::::::::::::::::::: 40 2.11.3 Syntactic Closures ::::::::::::::::::::::::::::::::::::::: 42 2.11.3.1 Syntax Terminology :::::::::::::::::::::::::::::::: 42 2.11.3.2 Transformer Definition:::::::::::::::::::::::::::::: 43 2.11.3.3 Identifiers :::::::::::::::::::::::::::::::::::::::::: 47 2.11.4 Explicit Renaming::::::::::::::::::::::::::::::::::::::: 49 2.12 SRFI syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 51 2.12.1 cond-expand (SRFI 0) ::::::::::::::::::::::::::::::::::: 52 2.12.2 receive (SRFI 8) ::::::::::::::::::::::::::::::::::::::::: 53 2.12.3 and-let* (SRFI 2) ::::::::::::::::::::::::::::::::::::::: 54 2.12.4 define-record-type (SRFI 9) :::::::::::::::::::::::::::::: 54 3 Equivalence Predicates :::::::::::::::::::::::: 57 4 Numbers :::::::::::::::::::::::::::::::::::::::: 63 4.1 Numerical types ::::::::::::::::::::::::::::::::::::::::::::::: 63 4.2 Exactness ::::::::::::::::::::::::::::::::::::::::::::::::::::: 64 4.3 Implementation restrictions :::::::::::::::::::::::::::::::::::: 64 4.4 Syntax of numerical constants ::::::::::::::::::::::::::::::::: 66 4.5 Numerical operations :::::::::::::::::::::::::::::::::::::::::: 66 4.6 Numerical input and output ::::::::::::::::::::::::::::::::::: 78 4.7 Fixnum and Flonum Operations ::::::::::::::::::::::::::::::: 81 4.7.1 Fixnum Operations ::::::::::::::::::::::::::::::::::::::: 81 4.7.2 Flonum Operations ::::::::::::::::::::::::::::::::::::::: 83 4.7.3 Floating-Point Environment :::::::::::::::::::::::::::::: 91 4.7.4 Floating-Point Exceptions :::::::::::::::::::::::::::::::: 92 4.7.5 Floating-Point Rounding Mode ::::::::::::::::::::::::::: 95 4.8 Random Number Generation :::::::::::::::::::::::::::::::::: 96 5 Characters :::::::::::::::::::::::::::::::::::::: 99 5.1 Character implementation :::::::::::::::::::::::::::::::::::: 102 5.2 Unicode :::::::::::::::::::::::::::::::::::::::::::::::::::::: 103 5.3 Character Sets ::::::::::::::::::::::::::::::::::::::::::::::: 105 6 Strings ::::::::::::::::::::::::::::::::::::::::: 107 6.1 Searching and Matching Strings :::::::::::::::::::::::::::::: 119 6.2 Regular Expressions :::::::::::::::::::::::::::::::::::::::::: 122 6.2.1 Regular S-Expressions ::::::::::::::::::::::::::::::::::: 122 6.2.2 Regsexp Procedures ::::::::::::::::::::::::::::::::::::: 127 v 7 Lists:::::::::::::::::::::::::::::::::::::::::::: 129 7.1 Pairs ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 130 7.2 Construction of Lists ::::::::::::::::::::::::::::::::::::::::: 132 7.3 Selecting List Components:::::::::::::::::::::::::::::::::::: 134 7.4 Cutting and Pasting Lists :::::::::::::::::::::::::::::::::::: 135 7.5 Filtering Lists :::::::::::::::::::::::::::::::::::::::::::::::: 137 7.6 Searching Lists ::::::::::::::::::::::::::::::::::::::::::::::: 138 7.7 Mapping of Lists ::::::::::::::::::::::::::::::::::::::::::::: 139 7.8 Folding of Lists::::::::::::::::::::::::::::::::::::::::::::::: 142 7.9 Miscellaneous List Operations :::::::::::::::::::::::::::::::: 144 8 Vectors :::::::::::::::::::::::::::::::::::::::: 147 8.1 Construction of Vectors :::::::::::::::::::::::::::::::::::::: 147 8.2 Selecting Vector Components ::::::::::::::::::::::::::::::::: 148 8.3 Cutting Vectors :::::::::::::::::::::::::::::::::::::::::::::: 149 8.4 Modifying Vectors :::::::::::::::::::::::::::::::::::::::::::: 150 9 Bit Strings::::::::::::::::::::::::::::::::::::: 151 9.1 Construction of Bit Strings ::::::::::::::::::::::::::::::::::: 151 9.2 Selecting Bit String Components ::::::::::::::::::::::::::::: 152 9.3 Cutting and Pasting Bit Strings :::::::::::::::::::::::::::::: 152 9.4 Bitwise Operations on Bit Strings :::::::::::::::::::::::::::: 153 9.5 Modification of Bit Strings ::::::::::::::::::::::::::::::::::: 153 9.6 Integer Conversions of Bit Strings :::::::::::::::::::::::::::: 154 10 Miscellaneous Datatypes :::::::::::::::::::: 155 10.1 Booleans :::::::::::::::::::::::::::::::::::::::::::::::::::: 155 10.2 Symbols::::::::::::::::::::::::::::::::::::::::::::::::::::: 156 10.3 Parameters:::::::::::::::::::::::::::::::::::::::::::::::::: 159 10.3.1 Cells ::::::::::::::::::::::::::::::::::::::::::::::::::: 160 10.4 Records ::::::::::::::::::::::::::::::::::::::::::::::::::::: 160 10.5 Promises :::::::::::::::::::::::::::::::::::::::::::::::::::: 162 10.6 Streams :::::::::::::::::::::::::::::::::::::::::::::::::::::
Load more

Recommended publications
  • Processing an Intermediate Representation Written in Lisp
    Processing an Intermediate Representation Written in Lisp Ricardo Pena,˜ Santiago Saavedra, Jaime Sanchez-Hern´ andez´ Complutense University of Madrid, Spain∗ [email protected],[email protected],[email protected] In the context of designing the verification platform CAVI-ART, we arrived to the need of deciding a textual format for our intermediate representation of programs. After considering several options, we finally decided to use S-expressions for that textual representation, and Common Lisp for processing it in order to obtain the verification conditions. In this paper, we discuss the benefits of this decision. S-expressions are homoiconic, i.e. they can be both considered as data and as code. We exploit this duality, and extensively use the facilities of the Common Lisp environment to make different processing with these textual representations. In particular, using a common compilation scheme we show that program execution, and verification condition generation, can be seen as two instantiations of the same generic process. 1 Introduction Building a verification platform such as CAVI-ART [7] is a challenging endeavour from many points of view. Some of the tasks require intensive research which can make advance the state of the art, as it is for instance the case of automatic invariant synthesis. Some others are not so challenging, but require a lot of pondering and discussion before arriving at a decision, in order to ensure that all the requirements have been taken into account. A bad or a too quick decision may have a profound influence in the rest of the activities, by doing them either more difficult, or longer, or more inefficient.
    [Show full text]
  • An Optimized R5RS Macro Expander
    An Optimized R5RS Macro Expander Sean Reque A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Jay McCarthy, Chair Eric Mercer Quinn Snell Department of Computer Science Brigham Young University February 2013 Copyright c 2013 Sean Reque All Rights Reserved ABSTRACT An Optimized R5RS Macro Expander Sean Reque Department of Computer Science, BYU Master of Science Macro systems allow programmers abstractions over the syntax of a programming language. This gives the programmer some of the same power posessed by a programming language designer, namely, the ability to extend the programming language to fit the needs of the programmer. The value of such systems has been demonstrated by their continued adoption in more languages and platforms. However, several barriers to widespread adoption of macro systems still exist. The language Racket [6] defines a small core of primitive language constructs, including a powerful macro system, upon which all other features are built. Because of this design, many features of other programming languages can be implemented through libraries, keeping the core language simple without sacrificing power or flexibility. However, slow macro expansion remains a lingering problem in the language's primary implementation, and in fact macro expansion currently dominates compile times for Racket modules and programs. Besides the typical problems associated with slow compile times, such as slower testing feedback, increased mental disruption during the programming process, and unscalable build times for large projects, slow macro expansion carries its own unique problems, such as poorer performance for IDEs and other software analysis tools.
    [Show full text]
  • Towards a Portable and Mobile Scheme Interpreter
    Towards a Portable and Mobile Scheme Interpreter Adrien Pi´erard Marc Feeley Universit´eParis 6 Universit´ede Montr´eal [email protected] [email protected] Abstract guage. Because Mobit implements R4RS Scheme [6], we must also The transfer of program data between the nodes of a distributed address the serialization of continuations. Our main contribution is system is a fundamental operation. It usually requires some form the demonstration of how this can be done while preserving the in- of data serialization. For a functional language such as Scheme it is terpreter’s maintainability and with local changes to the original in- clearly desirable to also allow the unrestricted transfer of functions terpreter’s structure, mainly through the use of unhygienic macros. between nodes. With the goal of developing a portable implemen- We start by giving an overview of the pertinent features of the tation of the Termite system we have designed the Mobit Scheme Termite dialect of Scheme. In Section 3 we explain the structure interpreter which supports unrestricted serialization of Scheme ob- of the interpreter on which Mobit is based. Object serialization is jects, including procedures and continuations. Mobit is derived discussed in Section 4. Section 5 compares Mobit’s performance from an existing Scheme in Scheme fast interpreter. We demon- with other interpreters. We conclude with related and future work. strate how macros were valuable in transforming the interpreter while preserving its structure and maintainability. Our performance 2. Termite evaluation shows that the run time speed of Mobit is comparable to Termite is a Scheme adaptation of the Erlang concurrency model.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems
    The Semantics of Syntax Applying Denotational Semantics to Hygienic Macro Systems Neelakantan R. Krishnaswami University of Birmingham <[email protected]> 1. Introduction body of a macro definition do not interfere with names oc- Typically, when semanticists hear the words “Scheme” or curring in the macro’s arguments. Consider this definition of and “Lisp”, what comes to mind is “untyped lambda calculus a short-circuiting operator: plus higher-order state and first-class control”. Given our (define-syntax and typical concerns, this seems to be the essence of Scheme: it (syntax-rules () is a dynamically typed applied lambda calculus that sup- ((and e1 e2) (let ((tmp e1)) ports mutable data and exposes first-class continuations to (if tmp the programmer. These features expose a complete com- e2 putational substrate to programmers so elegant that it can tmp))))) even be characterized mathematically; every monadically- representable effect can be implemented with state and first- In this definition, even if the variable tmp occurs freely class control [4]. in e2, it will not be in the scope of the variable definition However, these days even mundane languages like Java in the body of the and macro. As a result, it is important to support higher-order functions and state. So from the point interpret the body of the macro not merely as a piece of raw of view of a working programmer, the most distinctive fea- syntax, but as an alpha-equivalence class. ture of Scheme is something quite different – its support for 2.2 Open Recursion macros. The intuitive explanation is that a macro is a way of defining rewrites on abstract syntax trees.
    [Show full text]
  • Revised5report on the Algorithmic Language Scheme
    Revised5 Report on the Algorithmic Language Scheme RICHARD KELSEY, WILLIAM CLINGER, AND JONATHAN REES (Editors) H. ABELSON R. K. DYBVIG C. T. HAYNES G. J. ROZAS N. I. ADAMS IV D. P. FRIEDMAN E. KOHLBECKER G. L. STEELE JR. D. H. BARTLEY R. HALSTEAD D. OXLEY G. J. SUSSMAN G. BROOKS C. HANSON K. M. PITMAN M. WAND Dedicated to the Memory of Robert Hieb 20 February 1998 CONTENTS Introduction . 2 SUMMARY 1 Overview of Scheme . 3 1.1 Semantics . 3 The report gives a defining description of the program- 1.2 Syntax . 3 ming language Scheme. Scheme is a statically scoped and 1.3 Notation and terminology . 3 properly tail-recursive dialect of the Lisp programming 2 Lexical conventions . 5 language invented by Guy Lewis Steele Jr. and Gerald 2.1 Identifiers . 5 Jay Sussman. It was designed to have an exceptionally 2.2 Whitespace and comments . 5 clear and simple semantics and few different ways to form 2.3 Other notations . 5 expressions. A wide variety of programming paradigms, in- 3 Basic concepts . 6 3.1 Variables, syntactic keywords, and regions . 6 cluding imperative, functional, and message passing styles, 3.2 Disjointness of types . 6 find convenient expression in Scheme. 3.3 External representations . 6 The introduction offers a brief history of the language and 3.4 Storage model . 7 of the report. 3.5 Proper tail recursion . 7 4 Expressions . 8 The first three chapters present the fundamental ideas of 4.1 Primitive expression types . 8 the language and describe the notational conventions used 4.2 Derived expression types .
    [Show full text]
  • Towards a Portable and Mobile Scheme Interpreter
    Towards a Portable and Mobile Scheme Interpreter Adrien Pi´erard Marc Feeley Universit´eParis 6 Universit´ede Montr´eal [email protected] [email protected] Abstract guage. Because Mobit implements R4RS Scheme [6], we must also The transfer of program data between the nodes of a distributed address the serialization of continuations. Our main contribution is system is a fundamental operation. It usually requires some form the demonstration of how this can be done while preserving thein- of data serialization. For a functional language such as Scheme it is terpreter’s maintainability and with local changes to the original in- clearly desirable to also allow the unrestricted transfer offunctions terpreter’s structure, mainly through the use of unhygienicmacros. between nodes. With the goal of developing a portable implemen- We start by giving an overview of the pertinent features of the tation of the Termite system we have designed the Mobit Scheme Termite dialect of Scheme. In Section 3 we explain the structure interpreter which supports unrestricted serialization of Scheme ob- of the interpreter on which Mobit is based. Object serialization is jects, including procedures and continuations. Mobit is derived discussed in Section 4. Section 5 compares Mobit’s performance from an existing Scheme in Scheme fast interpreter. We demon- with other interpreters. We conclude with related and futurework. strate how macros were valuable in transforming the interpreter while preserving its structure and maintainability. Our performance 2. Termite evaluation shows that the run time speed of Mobit is comparable to Termite is a Scheme adaptation of the Erlang concurrency model.
    [Show full text]
  • What Macros Are and How to Write Correct Ones
    What Macros Are and How to Write Correct Ones Brian Goslinga University of Minnesota, Morris 600 E. 4th Street Morris, Minnesota 56267 [email protected] ABSTRACT such as Java and Scheme. There arise situations in most Macros are a powerful programming construct found in some high-level languages where code falls short of this ideal by programming languages. Macros can be thought of a way having redundancy and complexity not inherent to the prob- to define an abbreviation for some source code by providing lem being solved. Common abstraction mechanisms, such as a program that will take the abbreviated source code and functions and objects, are often unable to solve the problem return the unabbreviated version of it. In essence, macros [6]. Languages like Scheme provide macros to handle these enable the extension of the programming language by the situations. By using macros when appropriate, code can be programmer, thus allowing for compact programs. declarative, and thus easier to read, write, and understand. Although very powerful, macros can introduce subtle and Macros can be thought of as providing an abbreviation for hard to find errors in programs if the macro is not written common source code in a program. In English, an abbrevi- correctly. Some programming languages provide a hygienic ation (UMM) only makes sense if one knows how to expand macro system to ensure that macros written in that pro- it into what it stands for (University of Minnesota, Morris). gramming language do not result in these sort of errors. Likewise, macros undergo macro expansion to derive their In a programming language with a hygienic macro system, meaning.
    [Show full text]
  • Fully-Parameterized, First-Class Modules with Hygienic Macros
    Fully-parameterized, First-class Modules with Hygienic Macros Dissertation der Fakult¨at fur¨ Informations- und Kognitionswissenschaften der Eberhard-Karls-Universit¨at Tubingen¨ zur Erlangung des Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) vorgelegt von Dipl.-Inform. Josef Martin Gasbichler aus Biberach/Riß Tubingen¨ 2006 Tag der mundlichen¨ Qualifikation: 15. 02. 2006 Dekan: Prof. Dr. Michael Diehl 1. Berichterstatter: Prof. Dr. Herbert Klaeren 2. Berichterstatter: Prof. Dr. Peter Thiemann (Universit¨at Freiburg) Abstract It is possible to define a formal semantics for configuration, elaboration, linking, and evaluation of fully-parameterized first-class modules with hygienic macros, independent compilation, and code sharing. This dissertation defines such a semantics making use of explicit substitution to formalize hygienic expansion and linking. In the module system, interfaces define the static semantics of modules and include the definitions of exported macros. This enables full parameterization and independent compilation of modules even in the presence of macros. Thus modules are truly exchangeable components of the program. The basis for the module system is an operational semantics for hygienic macro expansion—computational macros as well as rewriting-based macros. The macro semantics provides deep insight into the nature of hygienic macro expansion through the use of explicit substitutions instead of conventional renaming techniques. The semantics also includes the formal description of Macro Scheme, the meta-language used for evaluating computational macros. Zusammenfassung Es ist m¨oglich, eine formale Semantik anzugeben, welche die Phasen Konfiguration, syntak- tische Analyse mit Makroexpansion, Linken und Auswertung fur¨ ein vollparametrisiertes Mo- dulsystem mit Modulen als Werten erster Klasse, unabh¨angiger Ubersetzung¨ und Code-Sharing beschreibt.
    [Show full text]
  • Types of Macros • Short for Macroinstruction
    9/16/14 CS152 – Advanced Programming Language Principles Prof. Tom Austin, Fall 2014 For next class, install LaTeX Macros (pronounced "LAH-tech") What is a macro? Types of macros • Short for macroinstruction. • A rule or pattern that specifies how a Text substitution certain input sequence should be mapped to a replacement sequence. Procedural macros Syntactic macros Text Substitution Macros A Review of Compilers This type of macro works by expanding text. Fast, but limited power. Some examples: source Lexer/ tokens Parser code Tokenizer • C preprocessor • Embedded languages (PHP, Ruby's erb, etc.) Abstract are similar, but more powerful Compiler Interpreter Syntax Tree (AST) Machine code Commands 1 9/16/14 Some variants work at the token level, but the C preprocessor example concept is the same. #define PI 3.14159 expanded source Pre- code Lexer/ tokens code Parser processor Tokenizer #define SWAP(a,b) {int tmp=a;a=b;b=tmp;} int main(void) { Abstract Compiler Interpreter int x=4, y=5, diam=7, circum=diam*PI; Syntax Tree SWAP(x,y); (AST) } Machine code Commands int main(void) { Procedural macros int x=4, y=5, diam=7, circum=diam*PI; SWAP(x,y); Preprocessor Procedural macros execute preprocessor } statements at compilation time. • Allows macros to be written in a procedural language. int main(void) { int x=4, y=5, diam=7, • More powerful than text substitution… circum=diam*3.14159; • …but slower and more complex compiler. {int tmp=x;x=y;y=tmp;}; } Syntactic macros Macro expansion process • Work at the level of abstract syntax trees Abstract Abstract Macro • From the Lisp family (including Scheme) Syntax Tree Syntax Tree Expander – Why Lisp? Because Lisp programs are ASTs (AST) (AST) • Powerful, but expensive • Where our attention will be focused Essentially this is a source-to-source compiler 2 9/16/14 Many macro systems suffer from a problem with inadvertent variable capture.
    [Show full text]
  • CSE341: Programming Languages Spring 2014 Unit 5 Summary Contents Switching from ML to Racket
    CSE341: Programming Languages Spring 2014 Unit 5 Summary Standard Description: This summary covers roughly the same material as class and recitation section. It can help to read about the material in a narrative style and to have the material for an entire unit of the course in a single document, especially when reviewing the material later. Please report errors in these notes, even typos. This summary is not a sufficient substitute for attending class, reading the associated code, etc. Contents Switching from ML to Racket ...................................... 1 Racket vs. Scheme ............................................. 2 Getting Started: Definitions, Functions, Lists (and if) ...................... 2 Syntax and Parentheses .......................................... 5 Dynamic Typing (and cond) ....................................... 6 Local bindings: let, let*, letrec, local define ............................ 7 Top-Level Definitions ............................................ 9 Bindings are Generally Mutable: set! Exists ............................ 9 The Truth about cons ........................................... 11 Cons cells are immutable, but there is mcons ............................. 11 Introduction to Delayed Evaluation and Thunks .......................... 12 Lazy Evaluation with Delay and Force ................................. 13 Streams .................................................... 14 Memoization ................................................. 15 Macros: The Key Points .........................................
    [Show full text]
  • A Tractable Scheme Implementation
    LISP AND SYMBOLIC COMPUTATION:An International Journal, 7, 315-335 (1994) © 1994 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands. A Tractable Scheme Implementation RICHARD A. KELSEY [email protected] NEC Research Institute JONATHAN A. REES [email protected] M1T and Cornell University Abstract. Scheme 48 is an implementation of the Scheme programming language constructed with tractability and reliability as its primary design goals. It has the structural properties of large, compiler-based Lisp implementations: it is written entirely in Scheme, is bootstrapped via its compiler, and provides numerous language extensions. It controls the complexity that ordinarily attends such large Lisp implementations through clear articulation of internal modularity and by the exclusion of features, optimizations, and generalizations that are of only marginal value. Keywords: byte-code interpreters, virtual machines, modularity, Scheme, partial evaluation, layered design 1. Introduction Scheme 48 is an implementation of the Scheme programming language constructed with tractability and reliability as its primary design goals. By tractability we mean the ease with which the system can be understood and changed. Although Lisp dialects, including Scheme, are relatively simple languages, implementation tractability is often threatened by the demands of providing high performance and extended functionality. The Scheme 48 project was initiated in order to experiment with techniques for main- taining implementation tractability in the face of countervailing pressures and to find out what tradeoffs were involved in doing so. (The project was originally an experiment to see if a Scheme implementation could be written in a single weekend; the 48 refers to forty-eight hours.) Small Lisp implementations are usually tractable merely by virtue of being small; it is usually possible for an experienced programmer to read and understand the entire source program in a few days.
    [Show full text]