The Internet Archive discovers and captures web pages through many different web crawls.
At any given time several distinct crawls are running, some for months, and some every day or longer.
View the web archive through the Wayback Machine.
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.
"An introduction to the project to restart the ANSI standard process for the Smalltalk programming language. This video was made to be shown at the Smalltalk 07 conference in Buenos Aires in December 2007."
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
working only from the standard, a conforming implementation can be produced,
Smalltalk programs which conform to the standard will have the same execution semantics on
any conforming implementation, and
the standard shall be sufficiently complete to allow useful Smalltalk programs to be
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:
constrain the nature of current and future implementations as little as possible, and
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
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
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
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
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.
Copyright 1999-2010 by Smalltalk.org, All Rights Reserved.