The Standard ML Basis Library

SML'96 Changes

Concurrent with, but mainly independent of, the design of the SML Standard Library has been work by the authors of the SML language to revise the language definition. In addition to simplifying and clarifying certain aspects of the original definition, the revision includes modest changes to the language that affect the programmer's use of the language and that address issues raised during the design of the library. For example, the revised language supports character literals, which greatly extends the expressiveness of the library's character types.

This chapter discusses the most significant of these changes, at least from the library's viewpoint. In addition, it describes in passing the changes concerning imperative/weak types and structure sharing, and notes incompatabilities between the current library proposal and the initial basis described in the original definition.


The new character type and the possibility of multiple implementations of the numeric types requires addressing the issue of literals.

Character literals

The revised definition extends the allowed escape sequences for characters to include:

  \a       Alert (ASCII 0x07)
  \b       Backspace (ASCII 0x08)
  \v       Vertical tab (ASCII 0x0B)
  \f       Form feed (ASCII 0x0C)
  \r       Carriage return (ASCII 0x0D)

There is additional notation for character literals:

where c is any legal string representing a single character. This notation has the advantage that existing legal SML code will not be affected.

Numeric literals

With the possibility of multiple representations of the numeric types in a given implementation (e.g., FixedInt and LargeInt), plus the introduction of word types, there needs to be a way to distinguish the different numeric literals. The revised definition specifies that numeric literals are viewed as overloaded symbols that, in the lack of additional type information, are given a default representation. Thus, the top-level binding

val x = 1
would give x the type, while
val x = (1 :
would give x the type as above. Note also that the following code would typecheck:
val x = (1 :
val y = x + 1
assuming that + is overloaded.

Hexadecimal integer constants are part of the revised language. Hexadecimal literals have the notation:

They are overloaded in the same way as ordinary integer literals.

The Basis Library supports word types, i.e., nonnegative integers with modular arithmetic corresponding to machine words. The revised definition provides decimal and hexadecimal word literals. Word literals will have a ``0w'' prefix; for example: 0w0, 0w10, or 0wxFF. Word literals do not have a sign.

Real literals are overloaded over the various real types for structures matching REAL, defaulting to Real.real. Real literals accept either `E' or `e' for the exponent.

Note that literals out of range should be detected at compile time.

Imperative types

As is well-known, imperative features such as ref and polymorphism cannot be combined naively without compromising type safety. Attempts to deal with this problem, using imperative type variables or weak types, have proven unsatisfactory, both because they are complex and unintuitive, and because they violate abstraction by exposing the pure or imperative nature of a computation in its type.

The revised definition of SML adopts value polymorphism to solve this problem. Specifically, in the expression

let val x = e in e' end
x is given a polymorphic type only if e is a syntactic value, i.e., e is a constant, a variable, a lambda expression, or a record, tuple or non-ref datatype value whose component parts are all syntactic values. This solution is not upward-compatible, in that certain expressions that are valid in SML will no longer type check. However, there is evidence that this solution is quite viable in practice. Most SML programs already restrict polymorphism to values and in most cases where non-value polymorphism is used, value polymorphism can be introduced by a small syntactic change. Given the enormous simplification this change effects, value polymorphism seems like the right solution.

Structure sharing

The original definition specified a very restrictive meaning to structure sharing. While retaining the original definition of type sharing, the revised definition reinterprets structure sharing as an abbreviation for a collection of type sharing specifications on the common type names among the specified structures.

Type abbreviations in signatures

Previously, types could occur in signatures only as a simple name or as a datatype definition. Although there are technical reasons for this decision, in practice this is too restrictive. In the future, type abbreviations can occur in signatures as well as structures. There is also a where type notation, which allows a programmer to extend a signature by adding definitions for its type components.

Opaque signature matching

To increase abstraction, it will be possible to match structures against signatures such that, unless the signature specifies the definition of a type as a datatype or a type abbreviation, the representation of the type is hidden outside of the structure.

Special types and values

The boolean constructors true and false, the list constructors nil and ::, and the reference constructor ref are treated specially. They are bound at top-level in the initial environment as datatype constructors, and cannot be rebound. Effectively, this makes them additional keywords, though technically they could be used as names for types, signatures, structures or functors. Note, in addition, that the bool and list types are defined at top-level and not in any module.

Basis library incompatibilities

The SML Standard Library is largely a conservative extension of the basis described in the original definition/, but there are a few points of incompatiblity worth noting:

The initial basis described in appendices C and D of the revised definition has been pruned to the bare minimum necessary to specify the semantics of the special constants and derived forms described in the definition.
[ INDEX | TOP | Parent | Root ]

Last Modified October 26, 1996
Copyright © 1996 AT&T