IEEE 1178-1990 en Standard for the Scheme Programming Language (IEEE Computer Society Document)《程序设计语言方案》.pdf

《IEEE 1178-1990 en Standard for the Scheme Programming Language (IEEE Computer Society Document)《程序设计语言方案》.pdf》由会员分享，可在线阅读，更多相关《IEEE 1178-1990 en Standard for the Scheme Programming Language (IEEE Computer Society Document)《程序设计语言方案》.pdf（81页珍藏版）》请在麦多课文档分享上搜索。

1、Copyright 1998 IEEE All Rights Reserved 1IEEE Std 1178-1990 (R2008)IEEE Standard for the Scheme Programming LanguageSponsorMicroprocessor and Microcomputer Standards Subcommitteeof theIEEE Computer SocietyApproved December 10, 1990Reaffirmed 27 March 2008IEEE Standards BoardAbstract: The form and me

2、aning of programs written in the Scheme programming language in particular,their syntax, the semantic rules for interpreting them, and the representation of data to be input or output bythem, are specified. The fundamental ideas of the language and the notational conventions used fordescribing and w

3、riting programs in the language are presented. The syntax and semantics of expressions,programs, and definitions are specified. Schemes built-in procedures, which include all of the languagesdata manipulation and input/output primitives, are described, and a formal syntax for Scheme written inextend

4、ed Backus-Naur form is provided. A formal denotational semantics for Schemes and some issues inthe implementation of Schemes arithmetic are covered in the appendixes.Keywords: Lisp, Scheme, Scheme programming languageThe Institute of Electrical and Electronics Engineers, Inc.345 East 47th Street, Ne

5、w York, NY 10017-2394, USA 1991 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 1991. Printed in the United States of AmericaLibrary of Congress Cataloging in Publication Data will be found in the following page.No part of this publication may be reproduc

6、ed in any form, in an electronic retrieval system or otherwise, withoutprior written permission of the publisher.iiIEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the StandardsCoordinating Committees of the IEEE Standards Board. Members of the committ

7、ees serve voluntarily and withoutcompensation. They are not necessarily members of the Institute. The standards developed within IEEE represent aconsensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE whichhave expressed an interest in partici

8、pating in the development of the standard.Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no otherways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEEStandard. Furthermore,

9、the viewpoint expressed at the time a standard is approved and issued is subject to changebrought about through developments in the state of the art and comments received from users of the standard. EveryIEEE Standard is subjected to review at least every five years for revision or reaffirmation. Wh

10、en a document is morethan five years old, and has not been reaffirmed, it is reasonable to conclude that its contents, although still of somevalue, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have thelatest edition of any IEEE Standard.Comm

11、ents for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliationwith IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together withappropriate supporting comments.Interpretations: Occasionally questions may

12、arise regarding the meaning of portions of standards as they relate tospecific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiateaction to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interest

13、s, it isimportant to ensure that any interpretation has also received the concurrence of a balance of interests. For this reasonIEEE and the members of its technical committees are not able to provide an instant response to interpretation requestsexcept in those cases where the matter has previously

14、 received formal consideration.Comments on standards and requests for interpretations should be addressed to:Secretary, IEEE Standards Board445 Hoes LaneP.O. Box 1331Piscataway, NJ 08555-1331USAISBN 1-55937-125-0IEEE Standards documents are adopted by the Institute of Electrical and Electronics Engi

15、neers without regard towhether their adoption may involve patents on articles, materials, or processes. Such adoption does not assumeany liability to any patent owner, nor does it assume any obligation whatever to l parties adopting the standardsdocuments.iiiForeword(This Foreword is not a part of I

16、EEE Std 1178-1990, IEEE Standard for the Scheme Programming Language.)Programming languages should be designed not by piling feature on top of feature, but by removing the weaknessesand restrictions that make additional features appear necessary. The Scheme programming language demonstrates thata ve

17、ry small number of rules for forming expressions, with few restrictions on how they are composed, suffice to forma practical and efficient programming language that is flexible enough to support most of the major programmingparadigms in use today.Scheme places few restrictions on the use of procedur

18、al abstractions: procedures are full first-class objects. AlthoughScheme is a block-structured language, and it permits side effects, it differs from most imperative block-structuredlanguages by encouraging a functional style of programming that uses procedures to encapsulate state.In a similar spir

19、it, Scheme implementations impose no storage penalty for tail-recursive procedure calls, andcontinuations (which are present, although behind the scenes, in all programming languages) are first-lass Schemeobjects that act like procedures. This permits nearly all known sequential control structures t

20、o be expressed in terms ofprocedure calls.Purpose of This StandardThroughout its thirty-year life, the Lisp family of languages has continually evolved to encompass changing ideasabout programming-language design. Scheme has participated in the evolution of Lisp. Scheme was one of the firstprogrammi

21、ng languages to incorporate first-lass procedures as in the lambda calculus, thereby proving the usefulnessof static scope rules and block structure in a dynamically typed language. Scheme was the first major dialect of Lispto distinguish procedures from lambda expressions and symbols, to use a sing

22、le lexical environment for all variables,and to evaluate the operator position of a procedure call in the same way as an operand position. Scheme was the firstwidely used programming language to rely entirely on procedure calls to express iteration and to embrace first-classescape procedures.Specify

23、ing a standard for Scheme is intended to encourage the continued evolution of Lisp dialects by identifying acoherent set of constructs that is large enough to support the implementation of substantial programs, but also smallenough to admit significant extensions and alternate approaches to language

24、 design. For example, this standard doesnot mandate the inclusion in Scheme of large run-time libraries, particular user interfaces, or complex interactions withexternal operating systems, although practical Scheme implementations ordinarily provide such features.In particular, there are important l

25、inguistic design issues that are not discussed in this standard precisely becauseScheme has sparked fruitful new approaches in these areas, and this working group does not wish to discourage thefurther development of good ideas by taking a position on issues under active investigation. Some of these

26、 issues aremacros, packaging, and object-oriented programming.The working group hopes that future revisions of this standard will be sensitive to the fact that good ideas need timeto mature, and that exploration can often be stifled by the premature adoption of standards.BackgroundThe first descript

27、ion of Scheme was written in 1975 B20.1 A revised report B17 appeared in 1978, which describedthe evolution of the language as its MIT implementation was upgraded to support an innovative compiler 4. Threedistinct projects began in 1981 and 1982 to use variants of Scheme for courses at MIT, Yale, an

28、d Indiana UniversityB14, B12, B6. An introductory computer science textbook using Scheme was published in 1984 B2.1See footnote 1, page 7.ivAs Scheme became more widespread, local dialects began to diverge until students and researchers occasionally foundit difficult to understand code written at ot

29、her sites. Fifteen representatives of the major implementations of Schemetherefore met in October 1984 to work toward a better and more widely accepted standard for Scheme. Their reportB4 was published at MIT and Indiana University in the summer of 1985. Subsequent rounds of revision took placein th

30、e spring of 1986 B15, and at a meeting that preceded the 1988 ACM Conference on Lisp and FunctionalProgramming B5. The working group for this standard first met at that same conference; the standard draws heavilyon the earlier reports.Readers interested in the evolution of the Scheme language are re

31、ferred to the above documents, and in particular tothe “Notes” following chapter 7 in B15 and B5.Members of the Scheme Working Group of the Microprocessor and Microcomputer Standards Subcommittee andthose who participated by correspondence were as follows:Christopher T. Haynes, Chair David H. Bartle

32、y, Chris Hanson, James S. Miller (Editors)Harold AbelsonNorman AdamsCyril N. AlbergaJoel F. BartlettScott BursonClyde CampBill CampbellJerome ChaillouxStewart ClamenWilliam ClingerPavel CurtisJeffrey DaltonOlivier DanvyKlaus DasslerKenneth DickeyBruce DubaR. Kent DybvigMarc FeeleyDaniel P. FriedmanM

33、ark FriedmanRichard P. GabrielJohn GateleyArthur GlecklerPatrick GreussayJed HarrisRobert HiebTakayasu ItoRoger KirchnerPaul KristoffTim McNerneyWilliam MaddoxSidney MarshallRobert MathisRichard MlynarikAndy NormanEric OstJohn D. RamsdellJonathan ReesGuillermo J. RozasBenjamin SchreiberGeorge Spring

34、erGuy L. Steele Jr.Gerald Jay SussmanEric TiedemannQueyen TranR. L. TritchardMitchell WandJon L. WhiteTaiichi YuasaThe following persons were on the balloting committee that approved this document for submission to the IEEEStandards Board:Harold AbelsonWilliam B. AdamsMohammad Al-MalkiDuane L. Ander

35、sonJoel F. BartlettDavid H. BartleyWinsor A. BrownLyle BurnettTodd BusniewskiCarl CaganMichael J. CaldwellGeorge CarsonDonald ChiDavid CohenPaul D. CookJ. R. DavisKenneth Alan DickeySu DongzhuangKent R. DybvigJeff S. EbertNeal M. GafterJohn GateleyTayeb GiumaWillard GravesGregory GuthrieChristopher

36、T. HaynesHerbert HechtRobert H. HyerleJohn JensenRichard KarcichEvan KirshenbaumPeter M. KoggeEzzat KoranyPaul KristoffTakahiko KukiTuvia LamdanJames S. MillerJohn E. MontagueKeith MorganCuong NguyenPeter OlsenJames R. OttoDon OxleyChandresh J. PatelCrispin PerdueRobert Pettengill, Jr.John D. Ramsde

37、llHans RoosliNorman SchneidewindDavid SeraphinMichael SmolinSerge SzukalowMitchell WandCarl WarrenW. L. WhippleFritz WhittingtonAndrew WilsonQiufeng WuOren YuenvThe final conditions for approval of this standard were met on December 10, 1990. This standard was conditionallyapproved by the IEEE Stand

38、ards Board on December 6, 1990, with the following membership:Marco W. Migliaro, Chair James M. Daly, Vice Chair Andrew G. Salem, Secretary Dennis BodsonPaul L. BorrillFletcher J. BuckleyAllen L. ClappStephen R. DillonDonald C. FleckensteinJay Forster*Thomas L. HannanKenneth D. HendrixJohn W. HorchJ

39、oseph L. Koepfinger*Irving KolodnyMichael A. LawlerDonald J. LoughryJohn E. May, Jr.Lawrence V. McCallL. Bruce McClungDonald T. Michael*Stig NilssonRoy T. OishiGary S. RobinsonTerrance R. WhittemoreDonald W. Zipse*Member EmeritusviCLAUSE PAGEIntroduction.1Objectives1Scope.1Future Directions.2Complia

40、nce .2Organization of the Document2Definitions of Terms .2Examples.3Base Document .3References.4Description of the Language .41. Overview of Scheme.41.1 Semantics . 41.2 Syntax. 51.3 Notation and Terminology . 52. Lexical Conventions .72.1 Identifiers . 72.2 Whitespace and Comments 82.3 Other Notati

41、ons 93. Basic Concepts93.1 Variables and Regions . 93.2 True and False 103.3 External Representations 103.4 Disjointness of Types. 103.5 Storage Model 114. Expressions .114.1 Primitive Expression Types . 124.2 Derived Expression Types . 145. Program Structure .205.1 Programs 205.2 Definitions 206. S

42、tandard Procedures22viiCLAUSE PAGE6.1 Booleans. 226.2 Equivalence Predicates 236.3 Pairs and Lists 266.4 Symbols 306.5 Numbers. 326.6 Characters. 426.7 Strings 436.8 Vectors . 456.9 Control Features. 466.10 Input and Output 497. Formal Syntax.517.1 Lexical Structure 517.2 External Representations 53

43、7.3 Expressions 537.4 Quasiquotations 547.5 Programs and Definitions. 557.6 Derived Expression Types . 557.6 Bibliography58Annex A (informative) Formal Semantics60Annex B (informative) Number System Subsets67Annex C (informative) Implementation of Numeric Datatypes .70Copyright 1991 IEEE All Rights

44、Reserved 1IEEE Standard for the Scheme Programming LanguageIntroductionObjectivesThis standard specifies the form and meaning of programs written in the Scheme programming language.Scheme was initially conceived as a vehicle for programming language research founded on a few key concepts thattogethe

45、r critically distinguish it from others in the related Algol and Lisp families of languages. Through severalindependent implementations, Scheme has evolved to include a commonly accepted base set of data types andprocedures as well as other features that are considered experimental or controversial.

46、The principal objective of this standard is to specify a language containing exactly those features for which there hasbeen extensive experience and thus a conservative consensus for standardization. This provides users with a basis forconstructing programs that are portable across implementations w

47、ithout jeopardizing research and future evolution ofthe language.ScopeThis standard specifies the representation of Scheme programs, their syntax, the semantic rules for interpreting them,and the representation of data to be input or output by them.This standard does not specify the mechanisms by wh

48、ich Scheme programs are transferred to and from systemmemory and placed into execution, or the size or complexity of a program and its data that will exceed the capacity ofa particular implementation.2 Copyright 1991 IEEE All Rights ReservedIEEE Std 1178-1990 IEEE STANDARD FORFuture DirectionsFuture

49、 revisions to this standard may be anticipated by a series of informal language specifications collectively knownas the “Revised Reports on the Algorithmic Language Scheme” (see B4,1 B15, B5). These reports extend thestandard language to include features that are considered mature enough to merit widespread implementation andexperimentation. Addition of such a feature to the report suggests that Scheme implementors should examine theaddition and carefully consider it as a candidate for formal standardization.ComplianceA conforming program shall use on