ANSI INCITS 319-1998 Information Technology - Programming Languages - Smalltalk.pdf

《ANSI INCITS 319-1998 Information Technology - Programming Languages - Smalltalk.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS 319-1998 Information Technology - Programming Languages - Smalltalk.pdf（292页珍藏版）》请在麦多课文档分享上搜索。

1、I ANSI INCITS 31 9-1 998 (formerly ANSI NCITS 31 9-1 998) for Information Technology - Programming Languages - Smalltalk Developed by SM Where IT all begins ANSI NCITS 31 9-1 998 American National Standard for Information Technology - Programming Languages - Smalltalk Secretariat Information Technol

2、ogy Industry Council Approved May 19, 1998 American National Standards Institute, Inc. Ame rica n National Standard Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards devel

3、oper. Consensus is established when, in the judgement of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all

4、views and objections be considered, and that a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purc

5、hasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give interpretation on any American National Standard. Moreover, no person shall have the right or authority to issue

6、 an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be r

7、evised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the

8、American National Standards Institute. CAUTION: The developers of this standard have requested that holders of patents that may be required for the implementation of the standard disclose such patents to the publisher. However, neither the developers nor the publisher have undertaken a patent search

9、 in order to identify which, if any, patents may apply to this standard. As of the date of publication of this standard and following calls for the identification of patents that may be required for the implementation of the standard, no such claims have been made. No further patent search is conduc

10、ted by the de- veloper or publisher in respect to any standard it processes. No representation is made or implied that licenses are not required to avoid infringement in the use of this standard. Published by American National Standards Institute, Inc. 11 West 42nd Street, New York, NY 10036 Copyrig

11、ht O 1998 by Information Technology Industry Council (ITI) All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of ITI, 1250 Eye Street NW, Washington, DC 20005. Printed in the United States o

12、f America Contents Page Foreword 1 2 3 3.1 3.2 3.3 3.4 3.5 3.6 4 4.1 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Goals and Scope . Conforming Implementations and Programs . The Smalltalk Language . 4 Computational Mo . 6 Method Grammar . Smalltalk Interchange Format Interchange Format BNF Syntax . Standar

13、d Class Library . 31 . 31 Standard Globals . . 44 Valuable Protocols . . 72 Exception Protocols . Numeric Protocols . Collection Protocols Date and Time Protocols . Stream Protocols . . 232 5.1 O File Stream Protocols . 269 6 Glossary 7 Index of Protocols . 8 References . . 284 I Foreword (This fore

14、word is not part of American National Standard NCITS 319-1998.) Smalltalk is designed to be a “single paradigm language with very simple semantics and syntax for specifying elements of a system and for describing system dynamics.“ The principle is explained by the designers of the original Smalltalk

15、-80 language. There is a continuing growth of interest in the language. Its use has spread beyond the education and research community to the commercial applications in recent years. Data from many sources (including polls in conferences and reports from inde- pendent consultants) indicate the growi

16、ng popularity of Smalltalk as an object-orient- ed programming language. There are currently at least five vendors of Smalltalk implementations. Although the actual number of Smalltalk users is unknown, we believe it to be high. (it has been estimated that Digitalk Inc., alone, had sold over 100,000

17、 SmalltalkN licenses by 1993.) Requests for interpretation, suggestions for improvement or addenda, or defect re- ports are welcome. They should be sent to the National Committe for Information Technology Standards (NCITS), ITI, 1250 Eye Street, NW, Suite 200, Washington, DC 20005. This standard was

18、 processed and approved for submittal to ANSI by NCITS. Com- mittee approval of this standard does not necessarily imply that all committee mem- bers voted for its approval. At the time it approved this standard, NCITS had the following members: Karen Higginbottom, Chair (Vacant), Vice-Chair Monica

19、Vago, Secretary Organization Represented Name of Representative AMP, Inc John Hill Apple Computer, Inc David Michael AT for example, class creation and global creation and initialization. These program constructs, rather, are provided via some combination of programming tools and imperative operatio

20、ns, .e., the evaluation of expressions in the language. The Committee decided that neither tools-based definitions nor imperative-based definitions of these important program constructs were adequate for a language standard. As a result, Chapter 3 not only provides syntax and semantics for Smalltalk

21、 methods, but also gives an explicit, declarative syntax and semantics for all constructs in a Smalltalk program. Chapter 4 gives a syntax for the format of files to be used for the interchange of Smalltalk programs among conforming implementations. The Standard is not defined in terms of file conte

22、nts, but this file format syntax is intended to allow conforming programs to be moved between conforming implementions. The Object Library specification in Chapter 5 has a scope that meets the Committees goals, and is implemented in a way that allows for specificity and for a significant amount of i

23、mplementor latitude. 1 ANSI NCITS 319-1998 The scope of the Library is roughly an intersection of existing Smalltalk products libraries. That is, it includes numbers, data structures (collections), basic objects (nil, Booleans, etc.), blocks, exceptions, and files. The intent is that the functionali

24、ty specified would be both complete and adequate to use for interesting applications. The standard attempts to minimize these definitions within the constraints of completeness and usability, so that implementors are not burdened with providing significantly more functionality than needed and so tha

25、t the size of the base library could be kept relatively small. The standard does not attempt to specify areas where current implementations differ in significant ways. In particular, as the goal statement implies, we did not include graphics, user interface, or database accessing objects in the libr

26、ary. Future revisions of this Standard may include a wider scope, especially if implementations converge. Traditionally Smalltalk class libraries have been specified via their implementation, providing the definition of a particular set of classes, including their state (instance variables) and meth

27、od implementations. This approach has major drawbacks in its use as a library specification; it constrains implementors to use exactly the implementation specified, and it can lead to less verifiable specifications. Rather than take this approach, we specify the Library in terms of the external beha

28、vior of the library objects. Implementors can take advantage of various implementation techniques as long as they deliver the specified external behavior. And this behavior must be rigorously specified. The main drawback of this approach, in particular with respect to the implementation-based approa

29、ch, is that the standard cannot specify the behavior of programs that subclass classes that implement the Standard Library. This is because, the behavior of such a subclass would be dependent upon implementation details of its superclass that are beyond the scope of this standard. Implementations ar

30、e free to have instance variables and internal methods in their implementations of these classes and those variables and methods cannot be guaranteed to not conflict with compliant programs instance variables and methods. For this reason, compliant programs cannot subclass most classes that implemen

31、t the Standard Library. The standard does specify a limited set of classes, including most notably Object, which may be subclassed by compliant programs. Implementation are required to implement these classes in a manner that will not conflict with the definition of subclasses. The standard uses a p

32、articular technique for specifying the external behavior of objects. This technique is based on a protocol, or type system. The protocol-based system is a lattice (.e., multiply-inherited) based system of collections of fully specified methods that follow strict conformance rules (which, by the way,

33、 is possible with protocolAype systems but is not feasible in implementation-based systems). A protocol will specify the external behavior of those objects in the Library that the Standard defines. In addition, a relatively small number of named Globals, objects whose behavior is defined by a protoc

34、ol, are specified. From these Globals, from the syntax-defined objects (e.g., program literals), and from the objects returned from messages sent to these objects, are produced the full set of objects defined in the Standard. Note that the protocol mechanism is only of use to the specification, it i

35、s not a part of the Smalltalk language. The standard does not require implementations to implement a protocol mechanism. Implementations of the Standard must only provide objects that conform to the protocols specifications. These objects may be instances or they may be classes; there is no requirem

36、ent that even the “class-like protocols need to be implemented with classes. The standard does not require that each protocol be implemented with separate objects - there may well be implementations where single objects conform to multiple protocols. As long as the external behavior of the objects i

37、s what is specified, then the implementation is conforming and programs that use these objects should be conforming. 2 ANSI NCITS 319-1998 M ust Accept Must Reject 2. Conforming Implementations and Programs Implementation- Unspecified Undefined Erroneous Defined .i .i .i May Vary Must Document .i .i

38、 .i .i .i if accepted 3 ANSI NCITS 319-1998 3. 3.1 The Smalltalk Language A Smalltalk program is a description of a dynamic computational process. The Smalltalk programming language is a notation for defining such programs. This definition of the Smalltalk language consist of two parts. The first pa

39、rt defines the abstract computational model for Smalltalk programs. It defines the environment within which a Smalltalk program executes and defines the entities that exist within that environment. The second part defines the notation used to specify Smalltalk programs. It defines the syntax and sem

40、antics of the language. Taken together the two parts are intended to define the semantics of a Smalltalk program, but avoid requiring any specific implementation techniques. The Smalltalk language defined in this chapter is an uniformly object-oriented programming language. It is uniform, in the sen

41、se that all data manipulated by a Smalltalk program is represented as objects. The language is a descendent of Smalltalk-80 Gold83,Gold89. The primary difference between ANSI Smalltalk and Smalltalk-80 is that ANSI Smalltalk provides for fully declarative specification of Smalltalk programs. In addi

42、tion, implementation dependencies and biases have been eliminated from the language. Computational Model of Smalltalk Execution A Smalltalk program is a means for describing a dynamic computational process. This section defines the entities that exist in the computational environment of Smalltalk pr

43、ograms. A variable is a computational entity that stores a single reference (the value of the variable) to an object. A message is a request to perform a designated computation. An object is a computational entity that is capable of responding to a well defined set of messages. An object may also en

44、capsulate some (possibly mutable) state. An object responds to a message by executing a method. Each method is identified by an associated method selector. A behavior is the set of methods used by an object to respond to messages. A method consists of a sequence of expressions. Program execution pro

45、ceeds by sequentially evaluating the expressions in one of more methods. There are three types of expressions: assignments, message sends, and returns. An assignment changes the value of a variable. A message send causes execution of the currently active method to be temporarily suspended and for pr

46、ogram execution to continue starting with the first expression of another method. A message send directs a message to an object. The object is called the receiverof the message. A message consists of a method selector and a set of arguments. Each argument is a reference to an object. When an object

47、receives a message, the method selector of the message is used to select the method from the objects behavior that corresponds to the selector. The method becomes the new locus of execution. Special processing takes place if the receivers behavior does not include a method corresponding to the messa

48、ges method selector. A return terminates execution of a method and causes execution to resume within the method that executed the message send that activated the method containing the return. Execution continues immediately following the message send expression. The return provides a value (an objec

49、t reference) that becomes the value of the message send. Within the text that defines a Smalltalk program, identifiers, called variable names, are used to refer to variables. A variable name is bound to a variable over some extent of the program definition. The extent within a program of such a binding is called the scope of the variable. The only 4 ANSI NCITS 319-1998 operations a program may perform upon a variable are to access its current value or to assign it a new value. The encapsulated state of an object consists of a (possibly empty) set of variables. Such varia