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-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 independent consultants) indicate the growing popularity of Smalltalk as an object-oriented programming language.

The growth, spread and potential of Smalltalk led to a need for a standard that will protect the users' interest in compatibility and portability. The J20 technical committee was formed in the summer of 1993 to develop the ANSI Smalltalk standard.

Programming Language Smalltalk
Document Number: ANSI/INCITS 319-1998
PDF page 5

1. Goals and Scope The goal of the J20 Committee was to produce a written standard for the Smalltalk language such that:

1. working only from the standard, a conforming implementation can be produced,
2. Smalltalk programs which conform to the standard will have the same execution semantics on any conforming implementation, and
3. the standard shall be sufficiently complete to allow useful Smalltalk programs to be constructed.

The standard does not specify the full range of class libraries one would expect to find in a Smalltalk implementation. For example, it specifies neither user-interface nor database frameworks. It does provide facilities to create such classes that will work on compliant implementations having identical external facilities to support them. Subject to the preceding points, the standard should:

1. constrain the nature of current and future implementations as little as possible, and
2. minimize impact on legacy code and implementations.

Although it was not the intent of the committee to produce a conformance tool or conformance test suite, the ability to define such conformance measures should be considered as a test of whether the standard is adequately unambiguous.

The following chapters specify the Smalltalk language in a way that is consistent with these goals.

• Chapter 2 specifies the terminology of conformance used in the standard.
• Chapter 3 specifies the language syntax and semantics.
• Chapter 4 specifies a standard interchange format for Smalltalk programs.
• Chapter 5 specifies the standard class library.
• Chapter 6 is a glossary of terms used in the document.

This is followed by an index of the protocols found in Chapter 5 and a list of references that, while not part of the standard, are referred to in the text of the standard. Most current Smalltalk implementations provide syntax and semantics only for Smalltalk methods. In particular, they do not provide an explicit definition of program construction, for example class creation and global creation and initialization. These program constructs, rather, are provided via some combination of programming tools and imperative operations, i.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 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 contents, 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 scope that meets the Committee's goals, and is implemented in a way that allows for specificity and allows for a significant amount of implementor latitude.

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 functionality 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 that 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 library. Future revisions of this Standard may include a wider scope, especially if implementations converge.

Traditionally Smalltalk class libraries has been specified via their implementation, providing the definition of a particular set of classes, including their state (instance variables) and method implementations. This approach has major drawbacks to use as a library specification; it constrains implementors to using 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 behavior 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 approach, 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 are free to have instance variables and internal methods in their implementations of these classes and those variables and methods cannot be guaranteed not to conflict with compliant programs' instance variables and methods. For this reason, compliant programs cannot subclass most classes that implement the Standard Library. The standard does specify a limited set of classes, including most notably Object, 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 particular 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 (i.e. multiply inherited) based system of collections of fully-specified methods that follow strict conformance rules (which, by the way, is possible with protocol/type 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 protocol, 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 is not a part of the Smalltalk language. The standard does not require implementations to implement a protocol mechanism. Implementations of the Standard only must provide object that conform to the protocol's specifications. These objects may be instances or they may be classes; there is no requirement that even the "class-like" protocols need to be implemented with classes. The standard does not require that each protocol isbe 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 is what is specified, then the implementation is conforming and programs that use these objects should be conforming.

---

Copyright 1997 National Committee for Information Technology Standards
Permission is granted to duplicate this document for the purpose of reviewing the draft standard.