Lambda, the Ultimate Label Or a Simple Optimizing Compiler for Scheme

Total Page:16

File Type:pdf, Size:1020Kb

Lambda, the Ultimate Label Or a Simple Optimizing Compiler for Scheme Lambda, the Ultimate Label or A Simple Optimizing Compiler for Scheme William D Clinger* Lars Thomas Hansen Lightship Software 1626 Arthur Place OACIS Eugene OR 97402 Tri-Step lth@cs. uoregon. edu University of Oregon Abstract is designed to reward more sophisticated register targeting, and to make register allocation easy to express by adjusting Optimizing compilers for higher-order languages need not the formal parameter lists of lambda expressions. Its de- be terriblv comdex. The Droblems created bv non-local. “ sign achieves some of the benefits of an intermediate e form non-globrd variables can be eliminated by allocating all such based on continuation-passing style (CP S) without actually variables in the heap. Lambda lifting makes this practical reauirin~ a conversion to CPS [23.1.181. by eliminating all non-local variables except for those that ‘Simp~icit y is achieved by a ‘front e~d whose two passes would have to be allocated in the heap anyway. The elimi- culminate in wholesale lambda iiftingl [3,1]. This lambda nated non-local variables become local variables that can be lifting is made possible by a cascade of simpler optimiza- allocated in registers. Since calls to known procedures are tion, of which the most important is a first order closure just gotos that pass arguments, lifted lambda expressions are analysis known as single assignment analysis. The output just assembly language labels that have been augmented by of the front end is an intermediate e form in which lambda a list of symbolic names for the registers that are live at that expressions are marked to indicate whether they correspond label. to assembly language labels (which represent both register allocation and control), to register allocation (let), or to 1 Introduction closure allocation. Portability is achieved by using a small, stylistically rigid Twobit is a compiler for Scheme in the tradition of Rabbit, subset of IEEE/ANSI Scheme [15] as the intermediate form, Orbit, and Gambit [23,16,9]. Unlike these previous com- in which quoted data in command positions (where the value pilers, which advanced the state of the art in generating is ignored) and stylistic variations convey additional infor- efficient code, the main design goals for Twobit were sim- mation to the code generator. This intermediate form can plicity, portability, and reasonably fast compilation, while be compiled correct~y by any Scheme compiler, but is de- generating code that is good enough for use in fairly high- signed as input to a code generator that will use the encoded performance systems comparable to Chez Scheme, Standard information. ML of New Jersev. and commercial imdementations of Com- The current code generator generates assembly code for a mon Lisp. The~e’ goals have been m’et. The fundamental hypothetical MacScheme machine similar to that described idea on which Twobit is built is that lambda expressions in [4], but register-based instead of stack-based. The Mac- can be viewed as assembly language labels, and the formal Scheme machine instructions have a semantics that was de- .Daramet ers of a lambda exmession. can be viewed as an in- signed for effective peephole optimization. Table-driven op- variant that asserts the contents of general registers that are timizing assemblers currently generate byte code for an in- live at that label. terpreter or machine code for the SPARC. Twobit has been None of the optimizations used in Twobit are new, but used to construct an implementation of Scheme2 known as their combined effectiveness has not been reported previ- Larceny, which has been used for research into the effect of ously, nor has the use of single assignment analysis for first programming style on the performance of Scheme programs order closure analysis. As explained in Section 14, the flow [11]. equation used for lambda lifting in Twobit has some advan- 1Lambda I]fting M called closure-conversion In [1] tages over the similar equations in [1], especially for a simple 2 Larceny is a nearly complete Implementation of IEEE/ANSI compiler. Scheme It is Incomplete mainly because of some bugs In the bignum Twobit is biased toward RISC architectures. The pri- dlv,smn routine mary goal of optimization in the front end is to reduce the problem of generating good code to a matter of register al- Permission to copy without fee all or part of this material is location and targeting. Currently the code generator is a granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the simple, conventional generator that allocates registers as a title of the publication and its date appear, and notice is given stack and performs no register targeting apart from choos- that copying is by permission of the Association of Computing ing an optimal order of evaluation for the operands of a Machinery. To copy otherwise, or to republish, requires a fee procedure call (parallel assignment optimization). Twobit and/or specific permission. * Current affiliation none of the below LISP 94- 6/94 Orlando, Florida USA (3 1994 ACM 0-89791 -643-3/94/0006..$3.50 128 Grammar for output of passes 1, 2, and 3: ((lambda () (begin L> .- (lambda (1-1 . ..) (set! reverse (begin D . ..) (lersbda (.x-2) (quote (R F <decls> <dot>) ((lambda (.1ooP-3) E) (begin 1 (lambda (1-1 . I-rest) (Set! .100p-3 (begin D . ..) (lambda (.x-5 y-5) (quote (R F <decls> <dot>)) (if (null? .x-5) E) y-s -. D> (define I L) (.1ooP-3 (cdr .x-5) -- 1?> (quote X) ; constants (cons (car .x-5) (begin I) ; variable references .y_5))))) / L lambda expressions ((lambda () (.1ooP-3 .x-2 ‘()))))) I (EO El . ..) ; calls ‘# !unspecified) ) ) (set ! I E) assignments ‘reverse) ) ) / (if EO El E2) ; conditionals I (begin EO El E2 . ..) ; sequent ial expressions -- 1> <identifier> Figure2: The output of Pass ]. R> -- ((I <references> <assignments> <calls>) . ..) F> -- (I . ..) Theoutputof Paes lisexpressed using therigidlystyl- ized subset of Scheme shown in Figure 1. Note especially Figure 1: The intermediate form. that avariable misrepresented by the equivalent (begin x), which gives to variable references a list structure that can be shared and side effected. The following invariants hold 2 Overview of Twobit for the output of Pass 1: ● There are no internal definitions. Twobit currently operates as a four-paxs compiler. An op- tional fifth pass is planned but not yet implemented. The ● Noidentifier containing an upper case letter is bound planned passes are any where.3 1. Standardization of syntax. ● Noidentifier is bound in more than one place. 2. Optimization. ● Each Rcontains one entry for every identifier bound 3. Representation inference (not yet implemented). in the formal parameter list and the internal defini- tion list that precede the R. Each entry contains a list 4. Code generation. of pointers to all references to the identifier, a list of pointers to all assignments to the identifier, and a list 5. Assembly. of pointers to all calls to the identifier. These passes will be discussed in order, using a definition of reverse as the main example: ● Except for constants, the expression does not share structure with the original input or itself, except that (define reverse the references and assignments in R are guaranteed to (lambda (x) share structure with the expression. Thus the expres- (define (loop x y) sion may beside effected, and side effects to references (if (null? x) or assignments obtained through R are guaranteed to Y change the references or assignments pointed to by R. (loop (cdr x) (cons (car x) y)))) (loopx ‘()))) ● F is garbage. In Scheme, any of the standard procedures can be re- Theintermediate form is acyclic, anditsprinted form is defined, which in combination with separate compilation genuine Scheme code, but it is large because of the shared means that a compiler cannot generate inline code for calls structure and is hard to read because of all the clutter. Pass to +, car, et cetera. Twobit, like most Scheme compilers, 1 converts the definition of reverse into an intermediate provides acompiler switch (titegrate-usual-procedures) form equivalent to the code shown in Figure 2, which was through which the programmer can promise not to redefine prodnced by a make-readable procedure. a subset of the standard procedures. The examples in this The#!unspecified notation in Figure 2, which stands paper assume that switch is true, which is the default. foracanonical unspecified value, wasprodnced bya partic- ular implementation of the letrec macro. This notation is 3 Pass 1: Standardization of syntax not a standard part of Scheme and is not treated specially by Twobit. Also, Scheme does not permit periods to be- Pass 1 expands macros, eliminates internal definitions, checks gin identifiers, but some such illegal prefix is advisable to syntax, andgives aunique name toeachlocal variable (alpha Sscheme is not case-sensitive. This paper assumes an implement~ conversion). In addition, Pass 1 creates for each local vari- tlon that standardizes variable names to lower case, which allows the able a table R containing all references, assignments, and compiler to use upper case names for its own purpoaefi, The handling procedure calls to that variable. of case is actuslly a parameter to the compiler 129 prevent the renamed local variables from shadowing global Since the single assignment probably resulted from the variables. The particular prefix used by Two bit is a param- elimination of an internal definition during Pass 1, it may eter of the compiler. seem that nothing has been accomplished. The key is that Pass 1 was designed as an extension of an efficient al- an internal definition in the output of Pass 2 records in- gorithm for hygienic macro expansion [6,7], but the current formation gained by a simple closure analysis, whereas an implement at ion still uses non-hygienic macros.
Recommended publications
  • Cognitive Programming Language (CPL) Programmer's Guide
    Cognitive Programming Language (CPL) Programmer's Guide 105-008-02 Revision C2 – 3/17/2006 *105-008-02* Copyright © 2006, Cognitive. Cognitive™, Cxi™, and Ci™ are trademarks of Cognitive. Microsoft® and Windows™ are trademarks of Microsoft Corporation. Other product and corporate names used in this document may be trademarks or registered trademarks of other companies, and are used only for explanation and to their owner’s benefit, without intent to infringe. All information in this document is subject to change without notice, and does not represent a commitment on the part of Cognitive. No part of this document may be reproduced for any reason or in any form, including electronic storage and retrieval, without the express permission of Cognitive. All program listings in this document are copyrighted and are the property of Cognitive and are provided without warranty. To contact Cognitive: Cognitive Solutions, Inc. 4403 Table Mountain Drive Suite A Golden, CO 80403 E-Mail: [email protected] Telephone: +1.800.525.2785 Fax: +1.303.273.1414 Table of Contents Introduction.............................................................................................. 1 Label Format Organization .................................................................. 2 Command Syntax................................................................................ 2 Important Programming Rules............................................................. 3 Related Publications...........................................................................
    [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]
  • A Compiler for a Simple Language. V0.16
    Project step 1 – a compiler for a simple language. v0.16 Change log: v0.16, changes from 0.15 Make all push types in compiler actions explicit. Simplified and better documentation of call and callr instruction compiler actions. Let the print statement print characters and numbers. Added a printv statement to print variables. Changed compiler actions for retr to push a variable value, not a literal value. Changes are shown in orange. v0.15, changes from 0.14 Change compiler actions for ret, retr, jmp. Change the description and compiler actions for poke. Change the description for swp. Change the compiler actions for call and callr. Changes shown in green. v0.14, changes from 0.13 Add peek, poke and swp instructions. Change popm compiler actions. Change callr compiler actions. Other small changes to wording. Changes are shown in blue. v0.13, changes from 0.12 Add a count field to subr, call and callr to simplify code generation. Changes are shown in red. v0.12 Changes from 0.11. Added a callr statement that takes a return type. Fix the generated code for this and for call to allow arguments to be pushed by the call. Add a retr that returns a value and update the reg. v0.11: changes from 0.10. Put typing into push operators. Put opcodes for compare operators. fix actions for call. Make declarations reserve a stack location. Remove redundant store instruction (popv does the same thing.) v0.10: changes from 0.0. Comparison operators (cmpe, cmplt, cmpgt) added. jump conditional (jmpc) added. bytecode values added.
    [Show full text]
  • Hy Documentation Release 0.12.1+64.G5eb9283
    hy Documentation Release 0.12.1+64.g5eb9283 Paul Tagliamonte Apr 14, 2017 Contents 1 Documentation Index 3 1.1 Quickstart................................................4 1.2 Tutorial..................................................5 1.2.1 Basic intro to Lisp for Pythonistas...............................5 1.2.2 Hy is a Lisp-flavored Python..................................7 1.2.3 Macros............................................. 12 1.2.4 Hy <-> Python interop..................................... 13 1.2.5 Protips!............................................. 14 1.3 Hy Style Guide.............................................. 14 1.3.1 Prelude............................................. 15 1.3.2 Layout & Indentation...................................... 15 1.3.3 Coding Style.......................................... 16 1.3.4 Conclusion........................................... 17 1.3.5 Thanks............................................. 17 1.4 Documentation Index.......................................... 18 1.4.1 Command Line Interface.................................... 18 1.4.2 Hy <-> Python interop..................................... 19 1.4.3 Hy (the language)........................................ 21 1.4.4 Hy Core............................................. 47 1.4.5 Reader Macros......................................... 65 1.4.6 Internal Hy Documentation................................... 66 1.5 Extra Modules Index........................................... 72 1.5.1 Anaphoric Macros....................................... 72 1.5.2
    [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]
  • Programming Basics - FORTRAN 77
    CWCS Workshop May 2005 Programming Basics - FORTRAN 77 http://www.physics.nau.edu/~bowman/PHY520/F77tutor/tutorial_77.html Program Organization A FORTRAN program is just a sequence of lines of plain text. This is called the source code. The text has to follow certain rules (syntax) to be a valid FORTRAN program. We start by looking at a simple example: program circle real r, area, pi c This program reads a real number r and prints c the area of a circle with radius r. write (*,*) 'Give radius r:' read (*,*) r pi = atan(1.0e0)*4.0e0 area = pi*r*r write (*,*) 'Area = ', area end A FORTRAN program generally consists of a main program and possibly several subprograms (i.e., functions or subroutines). The structure of a main program is: program name declarations statements end Note: Words that are in italics should not be taken as literal text, but rather as a description of what belongs in their place. FORTRAN is not case-sensitive, so "X" and "x" are the same variable. Blank spaces are ignored in Fortran 77. If you remove all blanks in a Fortran 77 program, the program is still acceptable to a compiler but almost unreadable to humans. Column position rules Fortran 77 is not a free-format language, but has a very strict set of rules for how the source code should be formatted. The most important rules are the column position rules: Col. 1: Blank, or a "c" or "*" for comments Col. 1-5: Blank or statement label Col. 6: Blank or a "+" for continuation of previous line Col.
    [Show full text]
  • An Industrial Strength Theorem Prover for a Logic Based on Common Lisp
    An Industrial Strength Theorem Prover for a Logic Based on Common Lisp y z Matt Kaufmannand J Strother Moore Personal use of this material is permitted. particular style of formal veri®cation that has shown consid- However, permission to reprint/republish this erable promise in recent years is the use of general-purpose material for advertising or promotional pur- automated reasoning systems to model systems and prove poses or for creating new collective works for properties of them. Every such reasoning system requires resale or redistribution to servers or lists, or considerable assistance from the user, which makes it im- to reuse any copyrighted component of this portant that the system provide convenient ways for the user work in other works must be obtained from the to interact with it. IEEE.1 One state-of-the-art general-purpose automated reason- ing system is ACL2: ªA Computational Logic for Applica- AbstractÐACL2 is a re-implemented extended version tive Common Lisp.º A number of automated reasoning of Boyer and Moore's Nqthm and Kaufmann's Pc-Nqthm, systems now exist, as we discuss below (Subsection 1.1). In intended for large scale veri®cation projects. This paper this paper we describe ACL2's offerings to the user for con- deals primarily with how we scaled up Nqthm's logic to an venientªindustrial-strengthºuse. WebegininSection2with ªindustrial strengthº programming language Ð namely, a a history of theACL2 project. Next, Section 3 describes the large applicative subset of Common Lisp Ð while preserv- logic supportedby ACL2, which has been designed for con- ing the use of total functions within the logic.
    [Show full text]
  • Fortran 90 Programmer's Reference
    Fortran 90 Programmer’s Reference First Edition Product Number: B3909DB Fortran 90 Compiler for HP-UX Document Number: B3908-90002 October 1998 Edition: First Document Number: B3908-90002 Remarks: Released October 1998. Initial release. Notice Copyright Hewlett-Packard Company 1998. All Rights Reserved. Reproduction, adaptation, or translation without prior written permission is prohibited, except as allowed under the copyright laws. The information contained in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material. Contents Preface . xix New in HP Fortran 90 V2.0. .xx Scope. xxi Notational conventions . xxii Command syntax . xxiii Associated documents . xxiv 1 Introduction to HP Fortran 90 . 1 HP Fortran 90 features . .2 Source format . .2 Data types . .2 Pointers . .3 Arrays . .3 Control constructs . .3 Operators . .4 Procedures. .4 Modules . .5 I/O features . .5 Intrinsics . .6 2 Language elements . 7 Character set . .8 Lexical tokens . .9 Names. .9 Program structure . .10 Statement labels . .10 Statements . .11 Source format of program file . .13 Free source form . .13 Source lines . .14 Statement labels . .14 Spaces . .14 Comments . .15 Statement continuation . .15 Fixed source form . .16 Spaces . .16 Source lines . .16 Table of Contents i INCLUDE line . 19 3 Data types and data objects . 21 Intrinsic data types . 22 Type declaration for intrinsic types .
    [Show full text]
  • Control Flow Graphs • Can Be Done at High Level Or Low Level – E.G., Constant Folding
    Optimizations • Code transformations to improve program – Mainly: improve execution time – Also: reduce program size Control Flow Graphs • Can be done at high level or low level – E.g., constant folding • Optimizations must be safe – Execution of transformed code must yield same results as the original code for all possible executions 1 2 Optimization Safety Optimization Safety • Safety of code transformations usually requires certain • Safety of code transformations usually requires certain information that may not be explicit in the code information which may not explicit in the code • Example: dead code elimination • Example: dead code elimination (1) x = y + 1; (1) x = y + 1; (2) y = 2 * z; (2) y = 2 * z; (3) x=y+z;x = y + z; (3) x=y+z;x = y + z; (4) z = 1; (4) z = 1; (5) z = x; (5) z = x; • What statements are dead and can be removed? • Need to know whether values assigned to x at (1) is never used later (i.e., x is dead at statement (1)) – Obvious for this simple example (with no control flow) – Not obvious for complex flow of control 3 4 1 Dead Variable Example Dead Variable Example • Add control flow to example: • Add control flow to example: x = y + 1; x = y + 1; y = 2 * z; y = 2 * z; if (d) x = y+z; if (d) x = y+z; z = 1; z = 1; z = x; z = x; • Statement x = y+1 is not dead code! • Is ‘x = y+1’ dead code? Is ‘z = 1’ dead code? •On some executions, value is used later 5 6 Dead Variable Example Dead Variable Example • Add more control flow: • Add more control flow: while (c) { while (c) { x = y + 1; x = y + 1; y = 2 * z; y = 2
    [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]