DOCSLIB.ORG

An Optimized R5RS Macro Expander

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. In order to improve macro expansion times for Racket, we implement an existing expansion algorithm for R5RS Scheme macros, which comprise a subset of Racket's macro system, and use that implementation to explore optimization opportunities. Our resulting expander appears to be the fastest implementation of a R5RS macro expander in a high-level language and performs several times faster than the existing C-based Racket implementation. Keywords: Macros, R5RS, Optimizations, Expander ACKNOWLEDGMENTS Without the support and guidance provided by Dr. McCarthy, this work would not have been possible. I am also indebted to BYU for providing an excellent learning environment and culture. I last of all thank my family for being the teachers in the most important school of my life. Table of Contents List of Figures viii List of Tables ix 1 Introduction 1 1.1 Thesis Statement . .1 1.2 Scheme Macros . .1 1.3 R5RS Scheme . .3 1.4 Problems with Conventional Macro Systems . .6 1.5 Related Work . 11 1.5.1 Gensym . 11 1.5.2 Timestamp Expander . 12 1.5.3 Syntactic Closures . 13 1.5.4 Explicit Renaming . 13 1.5.5 Mark/Antimark . 14 1.5.6 Fast Imperative Expander . 15 1.5.7 MetaML and MacroML . 15 1.5.8 Template Haskell . 16 1.5.9 Nemerle . 17 1.6 Optimization Approach . 17 1.7 Summary . 18 2 Explicit Renaming Algorithm 19 iv 2.1 Algorithm Overview . 19 2.2 R5RS syntax-rules ................................ 21 2.2.1 syntax-rules Grammar . 21 2.2.2 Interpreting syntax-rules Definitions . 23 2.2.3 Implementation Concerns . 25 2.3 Example Macro Expansion . 26 2.4 Summary . 29 3 Correctness and Performance Verification 30 3.1 Correctness and Performance Tests . 30 3.2 Testing Hardware . 30 3.3 Performance Goals . 31 3.4 Test Programs . 32 3.4.1 CK . 32 3.4.2 Dirty R5RS . 32 3.4.3 Macro Lambda . 33 3.4.4 Prime Numbers and the Sieve of Eratosthenes . 33 3.4.5 Fibonacci . 33 3.4.6 Schelog . 34 3.4.7 Monads . 34 3.5 Benchmarked Implementations . 35 3.5.1 Gambit . 35 3.5.2 Chicken . 35 3.5.3 Ikarus . 35 3.5.4 Chez . 36 3.5.5 Racket . 36 3.5.6 Fast Imperative Expander . 36 3.5.7 Other expanders . 36 v 3.6 Initial Benchmark Results . 36 3.7 Summary . 40 4 Optimizations 42 4.1 Data Structure Optimizations . 43 4.1.1 Pattern Matching Environment . 43 4.1.2 Template Regular Identifier Environments . 43 4.1.3 Removing the Quote Environment . 44 4.2 Lazy Computation Optimizations . 44 4.2.1 Lazy List Matching . 44 4.2.2 No Match Failure Diagnostics . 47 4.3 Redundant Computation Optimizations . 47 4.3.1 Unsafe Operations . 47 4.3.2 Optimizing body expansion . 49 4.3.3 Template List Rewriting . 50 4.4 Static Analysis Optimizations . 52 4.4.1 Constant Wrapping . 52 4.4.2 Template Pre-expansion . 52 4.4.3 Identifier Analysis . 54 4.5 Other Racket-Specific Optimizations . 56 4.5.1 Racket Keyword Arguments . 56 4.5.2 Hasheq vs Hash . 56 4.6 Optimization Results . 56 4.6.1 Lazy List Matching . 56 4.6.2 Unsafe Operations . 57 4.6.3 No Error Diagnosis . 58 4.6.4 Optimized Body Expansion . 58 4.6.5 Pattern Environment Vectors and Regular Identifier Vectors . 59 vi 4.6.6 Quote Environment Removal . 59 4.6.7 Optimized Template List Rewriting . 59 4.6.8 Hasheq and Keyword Arguments . 60 4.6.9 Template Pre-expansion . 60 4.6.10 Binding Inference . 60 4.6.11 Final Results . 61 4.7 Summary . 66 5 Conclusions 67 5.1 Current Issues . 68 5.2 Future Work . 68 5.3 Final Thoughts . 69 References 71 vii List of Figures 1.1 An example showing the use of the "and" macro with its subsequent expansion. 6 2.1 Explicit Renaming Example . 20 2.2 Simplified let definition and example use . 26 3.1 Initial \Heavyweight" Benchmarks . 38 3.2 Initial \Lightweight" Benchmarks . 39 4.1 R5RS letrec Definition . 46 4.2 Recursive rule of letrec . 46 4.3 Base case of letrec . 46 4.4 Optimized letrec pseudocode . 49 4.5 Specialized Definitions of map and foldr . 51 4.6 An example of template pre-expansion using the assert-eq macro . 53 4.7 Definition of glambda from the \dirtier macros" benchmark . 55 4.8 Impact of Optimizations on `Heavyweight' Benchmarks . 62 4.9 Impact of Optimizations on `Lightweight' Benchmarks . 63 4.10 Final \Heavyweight" Benchmarks . 64 4.11 Final \Lightweight" Benchmarks . 65 viii List of Tables 2.1 Simplified R5RS syntax-rules Grammar . 22 2.2 The Top-level Sub-Patterns, Matched Syntax, and Output Environments . 27 2.3 Sub-Templates of lambda Template and Their Output Syntax . 28 3.1 Benchmark Programs . 37 4.1 Mean and Median Performance Deltas Per Optimization . 57 ix Chapter 1 Introduction 1.1 Thesis Statement R5RS macro expansion can be optimized to enable the expansion of Scheme programs in a fraction of the time required by existing implementations. To support this claim, we implement an optimized R5RS macro expander based on an existing algorithm. We also show our methods for verifying the correctness and performance of our expander, and provide our results from benchmarking our expander against other major Scheme implementations. We show that our macro expander significantly outperforms all other open source macro expander implementations we tested and is competitive with the fastest known macro expander, Chez Scheme's proprietary expander. 1.2 Scheme Macros Macros systems as a programming language feature have been present in both.
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]
  • 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]
  • Structured Foreign Types
    Ftypes: Structured foreign types Andrew W. Keep R. Kent Dybvig Indiana University fakeep,[email protected] Abstract When accessing scalar elements within an ftype, the value of the High-level programming languages, like Scheme, typically repre- scalar is automatically marshaled into the equivalent Scheme rep- sent data in ways that differ from the host platform to support resentation. When setting scalar elements, the Scheme value is consistent behavior across platforms and automatic storage man- checked to ensure compatibility with the specified foreign type, and agement, i.e., garbage collection. While crucial to the program- then marshaled into the equivalent foreign representation. Ftypes ming model, differences in data representation can complicate in- are well integrated into the system, with compiler support for ef- teraction with foreign programs and libraries that employ machine- ficient access to foreign data and debugger support for convenient dependent data structures that do not readily support garbage col- inspection of foreign data. lection. To bridge this gap, many high-level languages feature for- The ftype syntax is convenient and flexible. While it is similar in eign function interfaces that include some ability to interact with some ways to foreign data declarations in other Scheme implemen- foreign data, though they often do not provide complete control tations, and language design is largely a matter of taste, we believe over the structure of foreign data, are not always fully integrated our syntax is cleaner and more intuitive than most. Our system also into the language and run-time system, and are often not as effi- has a more complete set of features, covering all C data types along cient as possible.
    [Show full text]
  • Chez Scheme Version 5 Release Notes Copyright C 1994 Cadence Research Systems All Rights Reserved October 1994 Overview 1. Funct
    Chez Scheme Version 5 Release Notes Copyright c 1994 Cadence Research Systems All Rights Reserved October 1994 Overview This document outlines the changes made to Chez Scheme for Version 5 since Version 4. New items include support for syntax-case and revised report high-level lexical macros, support for multiple values, support for guardians and weak pairs, support for generic ports, improved trace output, support for shared incremental heaps, support for passing single floats to and returning single floats from foreign procedures, support for passing structures to and returning structures from foreign procedures on MIPS-based computers, and various performance enhancements, including a dramatic improvement in the time it takes to load Scheme source and object files on DEC Ultrix MIPS-based computers. Overall performance of generated code has increased by an average of 15–50 percent over Version 4 depending upon optimize level and programming style. Programs that make extensive use of locally-defined procedures will benefit more than programs that rely heavily on globally-defined procedures, and programs compiled at higher optimize levels will improve more than programs compiled at lower optimize levels. Compile time is approximately 25 percent faster. Refer to the Chez Scheme System Manual, Revision 2.5 for detailed descriptions of the new or modified procedures and syntactic forms mentioned in these notes. Version 5 is available for the following platforms: • Sun Sparc SunOS 4.X & Solaris 2.X • DEC Alpha AXP OSF/1 V2.X • Silicon Graphics IRIX 5.X • Intel 80x86 NeXT Mach 3.2 • Motorola Delta MC88000 SVR3 & SVR4 • Decstation/Decsystem Ultrix 4.3A • Intel 80x86 BSDI BSD/386 1.1 • Intel 80x86 Linux This document contains four sections describing (1) functionality enhancements, (2) performance enhance- ments, (3) bugs fixed, and (4) compatibility issues.
    [Show full text]
  • Drscheme: a Pedagogic Programming Environment for Scheme
    DrScheme A Pedagogic Programming Environment for Scheme Rob ert Bruce Findler Cormac Flanagan Matthew Flatt Shriram Krishnamurthi and Matthias Felleisen Department of Computer Science Rice University Houston Texas Abstract Teaching intro ductory computing courses with Scheme el evates the intellectual level of the course and thus makes the sub ject more app ealing to students with scientic interests Unfortunatelythe p o or quality of the available programming environments negates many of the p edagogic advantages Toovercome this problem wehavedevel op ed DrScheme a comprehensive programming environmentforScheme It fully integrates a graphicsenriched editor a multilingua l parser that can pro cess a hierarchyofsyntactically restrictivevariants of Scheme a functional readevalprint lo op and an algebraical ly sensible printer The environment catches the typical syntactic mistakes of b eginners and pinp oints the exact source lo cation of runtime exceptions DrScheme also provides an algebraic stepp er a syntax checker and a static debugger The rst reduces Scheme programs including programs with assignment and control eects to values and eects The to ol is useful for explainin g the semantics of linguistic facilities and for studying the b ehavior of small programs The syntax c hecker annotates programs with fontandcolorchanges based on the syntactic structure of the pro gram It also draws arrows on demand that p oint from b ound to binding o ccurrences of identiers The static debugger roughly sp eaking pro vides a typ e inference system
    [Show full text]
  • Supplementary Material Forrebuilding Racket on Chez Scheme
    Supplementary Material for Rebuilding Racket on Chez Scheme (Experience Report) MATTHEW FLATT, University of Utah, USA CANER DERICI, Indiana University, USA R. KENT DYBVIG, Cisco Systems, Inc., USA ANDREW W. KEEP, Cisco Systems, Inc., USA GUSTAVO E. MASSACCESI, Universidad de Buenos Aires, Argentina SARAH SPALL, Indiana University, USA SAM TOBIN-HOCHSTADT, Indiana University, USA JON ZEPPIERI, independent researcher, USA All benchmark measurements were performed on an Intel Core i7-2600 3.4GHz processor running 64-bit Linux. Except as specifically noted, we used Chez Scheme 9.5.3 commit 7df2fb2e77 at github:cicso/ChezScheme, modified as commit 6d05b70e86 at github:racket/ChezScheme, and Racket 7.3.0.3 as commit ff95f1860a at github:racket/racket. 1 TRADITIONAL SCHEME BENCHMARKS The traditional Scheme benchmarks in figure1 are based on a suite of small programs that have been widely used to compare Scheme implementations. The benchmark sources are in the "common" directory of the racket-benchmarks package in the Racket GitHub repository. The results are in two groups, where the group starting with scheme-c uses mutable pairs, so they are run in Racket as #lang r5rs programs; for Racket CS we expect overhead due to the use of a record datatype for mutable pairs, instead of Chez Scheme’s built-in pairs. The groups are sorted by the ratio of times for Chez Scheme and the current Racket imple- mentation. Note that the break-even point is near the end of the first group. The racket collatz benchmark turns out to mostly measure the performance of the built-in division operator for rational numbers, while fft and nucleic benefit from flonum unboxing.
    [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]
  • 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]
  • 23 Things I Know About Modules for Scheme
    23 things I know about modules for Scheme Christian Queinnec Université Paris 6 — Pierre et Marie Curie LIP6, 4 place Jussieu, 75252 Paris Cedex — France [email protected] ABSTRACT difficult to deliver (or even rebuild) stand-alone systems. The benefits of modularization are well known. However, Interfaces as collection of names — If modules are about shar- modules are not standard in Scheme. This paper accompanies ing, what should be shared ? Values, locations (that is an invited talk at the Scheme Workshop 2002 on the current variables), types, classes (and their cortege` of accessors, state of modules for Scheme. Implementation is not addressed, constructors and predicates) ? only linguistic features are covered. Cave lector, this paper only reflects my own and instanta- The usual answer in Scheme is to share locations with neous biases! (quite often) two additional properties: (i) these loca- tions can only be mutated from the body of their defin- ing modules (this favors block compilation), (ii) they 1. MODULES should hold functions (and this should be statically (and The benefits of modularization within conventional languages easily) discoverable). This restricts linking with other are well known. Modules dissociate interfaces and implemen- (foreign) languages that may export locations holding tations; they allow separate compilation (or at least indepen- non-functional data (the errno location for instance). dent compilation a` la C). Modules tend to favor re-usability, This is not a big restriction since modern interfaces (Corba common libraries and cross language linkage. for example) tend to exclusively use functions (or meth- Modules discipline name spaces with explicit names expo- ods).
    [Show full text]
  • Programming Languages As Operating Systems
    Programming Languages as Op erating Systems (or Revenge of the Son of the Lisp Machine) Matthew Flatt Rob ert Bruce Findler Shriram Krishnamurthi Matthias Felleisen Department of Computer Science Rice University Houston, Texas 77005-1892 reclaim the program's resources|even though the program Abstract and DrScheme share a single virtual machine. The MrEd virtual machine serves b oth as the implementa- To address this problem, MrEd provides a small set of tion platform for the DrScheme programming environment, new language constructs. These constructs allow a program- and as the underlying Scheme engine for executing expres- running program, suchasDrScheme, to run nested programs sions and programs entered into DrScheme's read-eval-print directly on the MrEd virtual machine without sacri cing lo op. We describ e the key elements of the MrEd virtual control over the nested programs. As a result, DrScheme machine for building a programming environment, and we can execute a copyofDrScheme that is executing its own step through the implementation of a miniature version of copy of DrScheme (see Figure 1). The inner and middle DrScheme in MrEd. More generally,weshowhow MrEd de- DrSchemes cannot interfere with the op eration of the outer nes a high-level op erating system for graphical programs. DrScheme, and the middle DrScheme cannot interfere with the outer DrScheme's control over the inner DrScheme. In this pap er, we describ e the key elements of the MrEd 1 MrEd: A Scheme Machine virtual machine, and we step through the implementation of a miniature version of DrScheme in MrEd. More gen- The DrScheme programming environment [10] provides stu- erally,weshowhow MrEd de nes a high-level op erating dents and programmers with a user-friendly environment system (OS) for graphical programs.
    [Show full text]
  • CSE341: Programming Languages Lecture 15 Macros
    CSE341: Programming Languages Lecture 15 Macros Dan Grossman Winter 2013 What is a macro • A macro definition describes how to transform some new syntax into different syntax in the source language • A macro is one way to implement syntactic sugar – “Replace any syntax of the form e1 andalso e2 with if e1 then e2 else false” • A macro system is a language (or part of a larger language) for defining macros • Macro expansion is the process of rewriting the syntax for each macro use – Before a program is run (or even compiled) Winter 2013 CSE341: Programming Languages 2 Using Racket Macros • If you define a macro m in Racket, then m becomes a new special form: – Use (m …) gets expanded according to definition • Example definitions (actual definitions coming later): – Expand (my-if e1 then e2 else e3) to (if e1 e2 e3) – Expand (comment-out e1 e2) to e2 – Expand (my-delay e) to (mcons #f (lambda () e)) Winter 2013 CSE341: Programming Languages 3 Example uses It is like we added keywords to our language – Other keywords only keywords in uses of that macro – Syntax error if keywords misused – Rewriting (“expansion”) happens before execution (my-if x then y else z) ; (if x y z) (my-if x then y then z) ; syntax error (comment-out (car null) #f) (my-delay (begin (print "hi") (foo 15))) Winter 2013 CSE341: Programming Languages 4 Overuse Macros often deserve a bad reputation because they are often overused or used when functions would be better When in doubt, resist defining a macro? But they can be used well Winter 2013 CSE341: Programming Languages
    [Show full text]