Revised6 Report On The Algorithmic Language Scheme

3y ago
29 Views
2 Downloads
838.69 KB
90 Pages
Last View : 1m ago
Last Download : 3m ago
Upload by : Bennett Almond
Transcription

Revised6 Report on the Algorithmic LanguageSchemeMICHAEL SPERBERR. KENT DYBVIG, MATTHEW FLATT, ANTON VAN STRAATEN(Editors)RICHARD KELSEY, WILLIAM CLINGER, JONATHAN REES(Editors, Revised 5 Report on the Algorithmic Language Scheme)ROBERT BRUCE FINDLER, JACOB MATTHEWS(Authors, formal semantics)26 September 2007SUMMARYThe report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properlytail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It wasdesigned to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide varietyof programming paradigms, including functional, imperative, and message passing styles, find convenient expression inScheme.This report is accompanied by a report describing standard libraries [24]; references to this document are identified bydesignations such as “library section” or “library chapter”. It is also accompanied by a report containing non-normativeappendices [22]. A fourth report gives some historical background and rationales for many aspects of the language andits libraries [23].The individuals listed above are not the sole authors of the text of the report. Over the years, the following individualswere involved in discussions contributing to the design of the Scheme language, and were listed as authors of prior reports:Hal Abelson, Norman Adams, David Bartley, Gary Brooks, William Clinger, R. Kent Dybvig, Daniel Friedman, RobertHalstead, Chris Hanson, Christopher Haynes, Eugene Kohlbecker, Don Oxley, Kent Pitman, Jonathan Rees, GuillermoRozas, Guy L. Steele Jr., Gerald Jay Sussman, and Mitchell Wand.In order to highlight recent contributions, they are not listed as authors of this version of the report. However, theircontribution and service is gratefully acknowledged.We intend this report to belong to the entire Scheme community, and so we grant permission to copy it in whole or inpart without fee. In particular, we encourage implementors of Scheme to use this report as a starting point for manualsand other documentation, modifying it as necessary.

2Revised6 SchemeCONTENTSIntroduction . . . . . . . . . . . . . . . . . . . . . .Description of the language1 Overview of Scheme . . . . . . . . . . . . . . . . .1.1 Basic types . . . . . . . . . . . . . . . . . .1.2 Expressions . . . . . . . . . . . . . . . . . .1.3 Variables and binding . . . . . . . . . . . .1.4 Definitions . . . . . . . . . . . . . . . . . . .1.5 Forms . . . . . . . . . . . . . . . . . . . . .1.6 Procedures . . . . . . . . . . . . . . . . . .1.7 Procedure calls and syntactic keywords . . .1.8 Assignment . . . . . . . . . . . . . . . . . .1.9 Derived forms and macros . . . . . . . . . .1.10 Syntactic data and datum values . . . . . .1.11 Continuations . . . . . . . . . . . . . . . . .1.12 Libraries . . . . . . . . . . . . . . . . . . . .1.13 Top-level programs . . . . . . . . . . . . . .2 Requirement levels . . . . . . . . . . . . . . . . .3 Numbers . . . . . . . . . . . . . . . . . . . . . . .3.1 Numerical tower . . . . . . . . . . . . . . .3.2 Exactness . . . . . . . . . . . . . . . . . . .3.3 Fixnums and flonums . . . . . . . . . . . . .3.4 Implementation requirements . . . . . . . .3.5 Infinities and NaNs . . . . . . . . . . . . . .3.6 Distinguished -0.0 . . . . . . . . . . . . . .4 Lexical syntax and datum syntax . . . . . . . . .4.1 Notation . . . . . . . . . . . . . . . . . . . .4.2 Lexical syntax . . . . . . . . . . . . . . . . .4.3 Datum syntax . . . . . . . . . . . . . . . . .5 Semantic concepts . . . . . . . . . . . . . . . . . .5.1 Programs and libraries . . . . . . . . . . . .5.2 Variables, keywords, and regions . . . . . .5.3 Exceptional situations . . . . . . . . . . . .5.4 Argument checking . . . . . . . . . . . . . .5.5 Syntax violations . . . . . . . . . . . . . . .5.6 Safety . . . . . . . . . . . . . . . . . . . . .5.7 Boolean values . . . . . . . . . . . . . . . .5.8 Multiple return values . . . . . . . . . . . .5.9 Unspecified behavior . . . . . . . . . . . . .5.10 Storage model . . . . . . . . . . . . . . . . .5.11 Proper tail recursion . . . . . . . . . . . . .5.12 Dynamic extent and the dynamic environment6 Entry format . . . . . . . . . . . . . . . . . . . . .6.1 Syntax entries . . . . . . . . . . . . . . . . .6.2 Procedure entries . . . . . . . . . . . . . . .6.3 Implementation responsibilities . . . . . . .6.4 Other kinds of entries . . . . . . . . . . . .6.5 Equivalent entries . . . . . . . . . . . . . . .6.6 Evaluation examples . . . . . . . . . . . . .6.7 Naming conventions . . . . . . . . . . . . .7 Libraries . . . . . . . . . . . . . . . . . . . . . . 9191919202020202021212222222223237.1 Library form . . . . . . . . . .7.2 Import and export levels . . . .7.3 Examples . . . . . . . . . . . .8 Top-level programs . . . . . . . . . .8.1 Top-level program syntax . . .8.2 Top-level program semantics . .9 Primitive syntax . . . . . . . . . . . .9.1 Primitive expression types . . .9.2 Macros . . . . . . . . . . . . . .10 Expansion process . . . . . . . . . . .11 Base library . . . . . . . . . . . . . .11.1 Base types . . . . . . . . . . . .11.2 Definitions . . . . . . . . . . . .11.3 Bodies . . . . . . . . . . . . . .11.4 Expressions . . . . . . . . . . .11.5 Equivalence predicates . . . . .11.6 Procedure predicate . . . . . .11.7 Arithmetic . . . . . . . . . . . .11.8 Booleans . . . . . . . . . . . . .11.9 Pairs and lists . . . . . . . . . .11.10Symbols . . . . . . . . . . . . .11.11Characters . . . . . . . . . . . .11.12Strings . . . . . . . . . . . . . .11.13Vectors . . . . . . . . . . . . .11.14Errors and violations . . . . . .11.15Control features . . . . . . . . .11.16Iteration . . . . . . . . . . . . .11.17Quasiquotation . . . . . . . . .11.18Binding constructs for syntactic11.19Macro transformers . . . . . . .11.20Tail calls and tail contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .keywords. . . . . . . . . . .AppendicesA Formal semantics . . . . . . . . . . . . . . . . . .A.1 Background . . . . . . . . . . . . . . . . . .A.2 Grammar . . . . . . . . . . . . . . . . . . .A.3 Quote . . . . . . . . . . . . . . . . . . . . .A.4 Multiple values . . . . . . . . . . . . . . . .A.5 Exceptions . . . . . . . . . . . . . . . . . .A.6 Arithmetic and basic forms . . . . . . . . .A.7 Lists . . . . . . . . . . . . . . . . . . . . . .A.8 Eqv . . . . . . . . . . . . . . . . . . . . . .A.9 Procedures and application . . . . . . . . .A.10 Call/cc and dynamic wind . . . . . . . . . .A.11 Letrec . . . . . . . . . . . . . . . . . . . . .A.12 Underspecification . . . . . . . . . . . . . .B Sample definitions for derived forms . . . . . . . .C Additional material . . . . . . . . . . . . . . . . .D Example . . . . . . . . . . . . . . . . . . . . . . .E Language changes . . . . . . . . . . . . . . . . . .References . . . . . . . . . . . . . . . . . . . . . . . .Alphabetic index of definitions of concepts, keywords, and procedures . . . . . . . . . . . . . . 2

Introduction3INTRODUCTIONProgramming languages should be designed not by pilingfeature on top of feature, but by removing the weaknessesand restrictions that make additional features appear necessary. Scheme demonstrates that a very small number ofrules for forming expressions, with no restrictions on howthey are composed, suffice to form a practical and efficientprogramming language that is flexible enough to supportmost of the major programming paradigms in use today. make procedure calls powerful enough to express anyform of sequential control, and allow programs to perform non-local control operations without the use ofglobal program transformations;Scheme was one of the first programming languages to incorporate first-class procedures as in the lambda calculus,thereby proving the usefulness of static scope rules andblock structure in a dynamically typed language. Schemewas the first major dialect of Lisp to distinguish procedures from lambda expressions and symbols, to use a single lexical environment for all variables, and to evaluatethe operator position of a procedure call in the same wayas an operand position. By relying entirely on procedurecalls to express iteration, Scheme emphasized the fact thattail-recursive procedure calls are essentially gotos that passarguments. Scheme was the first widely used programminglanguage to embrace first-class escape procedures, fromwhich all previously known sequential control structurescan be synthesized. A subsequent version of Scheme introduced the concept of exact and inexact number objects,an extension of Common Lisp’s generic arithmetic. Morerecently, Scheme became the first programming languageto support hygienic macros, which permit the syntax of ablock-structured language to be extended in a consistentand reliable manner. allow educators to use the language to teach programming effectively, at various levels and with a variety ofpedagogical approaches; andGuiding principlesTo help guide the standardization effort, the editors haveadopted a set of principles, presented below. Like theScheme language defined in Revised5 Report on the Algorithmic Language Scheme [14], the language described inthis report is intended to: allow programmers to read each other’s code, and allow development of portable programs that can be executed in any conforming implementation of Scheme; derive its power from simplicity, a small number ofgenerally useful core syntactic forms and procedures,and no unnecessary restrictions on how they are composed; allow programs to define new procedures and new hygienic syntactic forms; support the representation of program source code asdata; allow interesting, purely functional programs to runindefinitely without terminating or running out ofmemory on finite-memory machines; allow researchers to use the language to explore the design, implementation, and semantics of programminglanguages.In addition, this report is intended to: allow programmers to create and distribute substantial programs and libraries, e.g., implementations ofScheme Requests for Implementation, that run without modification in a variety of Scheme implementations; support procedural, syntactic, and data abstractionmore fully by allowing programs to define hygienebending and hygiene-breaking syntactic abstractionsand new unique datatypes along with procedures andhygienic macros in any scope; allow programmers to rely on a level of automatic runtime type and bounds checking sufficient to ensuretype safety; and allow implementations to generate efficient code, without requiring programmers to use implementationspecific operators or declarations.While it was possible to write portable programs in Schemeas described in Revised5 Report on the Algorithmic Language Scheme, and indeed portable Scheme programs werewritten prior to this report, many Scheme programs werenot, primarily because of the lack of substantial standardized libraries and the proliferation of implementationspecific language additions.In general, Scheme should include building blocks that allow a wide variety of libraries to be written, include commonly used user-level features to enhance portability andreadability of library and application code, and exclude features that are less commonly used and easily implementedin separate libraries.The language described in this report is intended to also bebackward compatible with programs written in Scheme as

4Revised6 Schemedescribed in Revised5 Report on the Algorithmic LanguageScheme to the extent possible without compromising theabove principles and future viability of the language. Withrespect to future viability, the editors have operated underthe assumption that many more Scheme programs will bewritten in the future than exist in the present, so the future programs are those with which we should be mostconcerned.AcknowledgementsMany people contributed significant help to this revisionof the report. Specifically, we thank Aziz Ghuloum andAndré van Tonder for contributing reference implementations of the library system. We thank Alan Bawden,John Cowan, Sebastian Egner, Aubrey Jaffer, Shiro Kawai,Bradley Lucier, and André van Tonder for contributing insights on language design. Marc Feeley, Martin Gasbichler,Aubrey Jaffer, Lars T Hansen, Richard Kelsey, Olin Shivers, and André van Tonder wrote SRFIs that served asdirect input to the report. Marcus Crestani, David Frese,Aziz Ghuloum, Arthur A. Gleckler, Eric Knauel, JonathanRees, and André van Tonder thoroughly proofread earlyversions of the report.We would also like to thank the following people for theirhelp in creating this report: Lauri Alanko, Eli Barzilay,Alan Bawden, Brian C. Barnes, Per Bothner, Trent Buck,Thomas Bushnell, Taylor Campbell, Ludovic Courtès, Pascal Costanza, John Cowan, Ray Dillinger, Jed Davis, J.A.“Biep” Durieux, Carl Eastlund, Sebastian Egner, TomEmerson, Marc Feeley, Matthias Felleisen, Andy Freeman, Ken Friedenbach, Martin Gasbichler, Arthur A.Gleckler, Aziz Ghuloum, Dave Gurnell, Lars T Hansen,Ben Harris, Sven Hartrumpf, Dave Herman, Nils M.Holm, Stanislav Ievlev, James Jackson, Aubrey Jaffer,Shiro Kawai, Alexander Kjeldaas, Eric Knauel, MichaelLenaghan, Felix Klock, Donovan Kolbly, Marcin Kowalczyk, Thomas Lord, Bradley Lucier, Paulo J. Matos, DanMuresan, Ryan Newton, Jason Orendorff, Erich Rast,Jeff Read, Jonathan Rees, Jorgen Schäfer, Paul Schlie,Manuel Serrano, Olin Shivers, Jonathan Shapiro, Jens AxelSøgaard, Jay Sulzberger, Pinku Surana, Mikael Tillenius,Sam Tobin-Hochstadt, David Van Horn, André van Tonder, Reinder Verlinde, Alan Watson, Andrew Wilcox, JonWilson, Lynn Winebarger, Keith Wright, and ChongkaiZhu.We would like to thank the following people for their helpin creating the previous revisions of this report: AlanBawden, Michael Blair, George Carrette, Andy Cromarty,Pavel Curtis, Jeff Dalton, Olivier Danvy, Ken Dickey,Bruce Duba, Marc Feeley, Andy Freeman, Richard Gabriel,Yekta Gürsel, Ken Haase, Robert Hieb, Paul Hudak,Morry Katz, Chris Lindblad, Mark Meyer, Jim Miller, JimPhilbin, John Ramsdell, Mike Shaff, Jonathan Shapiro,Julie Sussman, Perry Wagle, Daniel Weise, Henry Wu, andOzan Yigit.We thank Carol Fessenden, Daniel Friedman, and Christopher Haynes for permission to use text from the Scheme311 version 4 reference manual. We thank Texas Instruments, Inc. for permission to use text from the TIScheme Language Reference Manual [26]. We gladly acknowledge the influence of manuals for MIT Scheme [20],T [21], Scheme 84 [12], Common Lisp [25], Chez Scheme [8],PLT Scheme [11], and Algol 60 [1].We also thank Betty Dexter for the extreme effort she putinto setting this report in TEX, and Donald Knuth for designing the program that caused her troubles.The Artificial Intelligence Laboratory of the MassachusettsInstitute of Technology, the Computer Science Departmentof Indiana University, the Computer and Information Sciences Department of the University of Oregon, and theNEC Research Institute supported the preparation of thisreport. Support for the MIT work was provided in part bythe Advanced Research Projects Agency of the Departmentof Defense under Office of Naval Research contract N0001480-C-0505. Support for the Indiana University work wasprovided by NSF grants NCS 83-04567 and NCS 83-03325.

1. Overview of Scheme5DESCRIPTION OF THE LANGUAGE1.Overview of SchemeThis chapter gives an overview of Scheme’s semantics. Thepurpose of this overview is to explain enough about the basic concepts of the language to facilitate understanding ofthe subsequent chapters of the report, which are organizedas a reference manual. Consequently, this overview is nota complete introduction to the language, nor is it precisein all respects or normative in any way.Following Algol, Scheme is a statically scoped programming language. Each use of a variable is associated with alexically apparent binding of that variable.Scheme has latent as opposed to manifest types [28]. Typesare associated with objects (also called values) rather thanwith variables. (Some authors refer to languages with latent types as untyped, weakly typed or dynamically typedlanguages.) Other languages with latent types are Python,Ruby, Smalltalk, and other dialects of Lisp. Languageswith manifest types (sometimes referred to as stronglytyped or statically typed languages) include Algol 60, C,C#, Java, Haskell, and ML.All objects created in the course of a Scheme computation,including procedures and continuations, have unlimited extent. No Scheme object is ever destroyed. The reason thatimplementations of Scheme do not (usually!) run out ofstorage is that they are permitted to reclaim the storageoccupied by an object if they can prove that the objectcannot possibly matter to any future computation. Otherlanguages in which most objects have unlimited extent include C#, Java, Haskell, most Lisp dialects, ML, Python,Ruby, and Smalltalk.Implementations of Scheme must be properly tailrecursive. This allows the execution of an iterative computation in constant space, even if the iterative computation is described by a syntactically recursive procedure.Thus with a properly tail-recursive implementation, iteration can be expressed using the ordinary procedure-callmechanics, so that special iteration constructs are usefulonly as syntactic sugar.Scheme was one of the first languages to support procedures as objects in their own right. Procedures can becreated dynamically, stored in data structures, returnedas results of procedures, and so on. Other languages withthese properties include Common Lisp, Haskell, ML, Ruby,and Smalltalk.One distinguishing feature of Scheme is that continuations,which in most other languages only operate behind thescenes, also have “first-class” status. First-class continuations are useful for implementing a wide variety of advanced control constructs, including non-local exits, backtracking, and coroutines.In Scheme, the argument expressions of a procedure callare evaluated before the procedure gains control, whetherthe procedure needs the result of the evaluation or not.C, C#, Common Lisp, Python, Ruby, and Smalltalk areother languages that always evaluate argument expressionsbefore invoking a procedure. This is distinct from the lazyevaluation semantics of Haskell, or the call-by-name semantics of Algol 60, where an argument expression is notevaluated unless its value is needed by the procedure.Scheme’s model of arithmetic provides a rich set of numerical types and operations on them. Furthermore, it distinguishes exact and inexact number objects: Essentially, anexact number object corresponds to a number exactly, andan inexact number object is the result of a computationthat involved rounding or other errors.1.1. Basic typesScheme programs manipulate objects, which are also referred to as values. Scheme objects are organized into setsof values called types. This section gives an overview of thefundamentally important types of the Scheme language.More types are described in later chapters.Note: As Scheme is latently typed, the use of the term typein this report differs from the use of the term in the context ofother languages, particularly those with manifest typing.Booleans A boolean is a truth value, and can be eithertrue or false. In Scheme, the object for “false” is written #f.The object for “true” is written #t. In most places where atruth value is expected, however, any object different from#f counts as true.Numbers Scheme su

Revised6 Report on the Algorithmic Language Scheme MICHAEL SPERBER R. KENT DYBVIG, MATTHEW FLATT, ANTON VAN STRAATEN (Editors) RICHARD KELSEY, WILLIAM CLINGER, JONATHAN REES (Editors, Revised5 Report on the Algorithmic Language Scheme) ROBERT BRUCE FINDLER, JACOB MATTHEWS (Authors, formal semantics) 26 September 2007 SUMMARY The report gives a defining description of the programming language .

Related Documents:

May 02, 2018 · D. Program Evaluation ͟The organization has provided a description of the framework for how each program will be evaluated. The framework should include all the elements below: ͟The evaluation methods are cost-effective for the organization ͟Quantitative and qualitative data is being collected (at Basics tier, data collection must have begun)

Silat is a combative art of self-defense and survival rooted from Matay archipelago. It was traced at thé early of Langkasuka Kingdom (2nd century CE) till thé reign of Melaka (Malaysia) Sultanate era (13th century). Silat has now evolved to become part of social culture and tradition with thé appearance of a fine physical and spiritual .

On an exceptional basis, Member States may request UNESCO to provide thé candidates with access to thé platform so they can complète thé form by themselves. Thèse requests must be addressed to esd rize unesco. or by 15 A ril 2021 UNESCO will provide thé nomineewith accessto thé platform via their émail address.

̶The leading indicator of employee engagement is based on the quality of the relationship between employee and supervisor Empower your managers! ̶Help them understand the impact on the organization ̶Share important changes, plan options, tasks, and deadlines ̶Provide key messages and talking points ̶Prepare them to answer employee questions

Dr. Sunita Bharatwal** Dr. Pawan Garga*** Abstract Customer satisfaction is derived from thè functionalities and values, a product or Service can provide. The current study aims to segregate thè dimensions of ordine Service quality and gather insights on its impact on web shopping. The trends of purchases have

Chính Văn.- Còn đức Thế tôn thì tuệ giác cực kỳ trong sạch 8: hiện hành bất nhị 9, đạt đến vô tướng 10, đứng vào chỗ đứng của các đức Thế tôn 11, thể hiện tính bình đẳng của các Ngài, đến chỗ không còn chướng ngại 12, giáo pháp không thể khuynh đảo, tâm thức không bị cản trở, cái được

Le genou de Lucy. Odile Jacob. 1999. Coppens Y. Pré-textes. L’homme préhistorique en morceaux. Eds Odile Jacob. 2011. Costentin J., Delaveau P. Café, thé, chocolat, les bons effets sur le cerveau et pour le corps. Editions Odile Jacob. 2010. Crawford M., Marsh D. The driving force : food in human evolution and the future.

Korean Language (Level 1) Course Code 008.199 Class Times Mon/Wed/Thu 16:00-18:00 Classroom TBA Equivalent Year Level 2 Course Credit 2 Instructor Changdeok, Hahm Sessions 1-14 Office Bld.1, Rm. 313 Email tentiger@snu.ac.kr Instructor’s Profile Changdeok, Hahm Full-time lecturer, Korean Language, Language Education Institute, Seoul National University As a Korean language teacher, Changdeok .