Dylan Design Notes
When we released the first edition of the Dylan manual in April, 1992 we
invited feedback. The Dylan Design Notes, describing changes to the
Dylan language design, are a result of that feedback.
The goal of the Dylan language design process has been to clarify
ambiguities, remove inconsistencies, and increase the efficiency of the
language. The overall goal of Dylan is to better meet the needs of
mainstream application programmers.
The document is divided into a number of Design Notes.
Each Note describes a single change or new feature of the language. The
Dylan Manual and the Design Notes, taken together, define the Dylan
We invite your continued feedback.
Table of Contents
- Design Note Format
- #1: Collection Class-For-Copy (Clarification)
- This design note clarifies that class-for-copy of a collection must
return a mutable collection.
- #2: First, Second, Third, Last Default (Addition)
This design note adds a default: keyword argument to the
specification of the functions first, second, third, and last. This
change removes a possible source of confusion by making these
functions more consistent with the function element.
- #3: Make Class Specification (Addition)
- This design note gives an expanded specification for <class> which
enables new classes to be created at runtime, with make.
- #4: No Incremental Class Modifications (Change)
This design note deletes the functions add-slot and remove-slot, the
setter for direct-superclasses, and the macro define-slot from the
Dylan language specification.
- #5: Regularization of the Type System (Change)
This design note outlines a more expressive type system for Dylan.
Not all types in Dylan are classes. For example, singleton types are
not classes. The new type system allows for a variety of types,
including classes and singleton types, and also provides a framework
for introducing additional types that are not classes.
- #6: Limited Types (Addition)
- This design note introduces a new generic function, limited, for
constructing limited types, and specific methods for creating limited
integer types and limited collection types. For example, (limited
<integer> min: 0 max: 255) and (limited <array> of: <single-float>)
are useful types.
- #7: Union Types (Addition)
- This design note introduces a new facility for creating a union type
as a union of two other types. Union types are useful as slot
specializers, and describe the return types of many common functions.
For example, (union <integer> (singleton #f)) describes the return
type of size.
- #8: Method Dispatch Ambiguity (Clarification)
- Sometimes it is not clear which of two methods is the most specific
for a particular function call. This is a particular problem for
non-class types because it is possible for an object to be an
instance of two disjoint types, such as (limited <integer> min: 0)
and (limited <integer> max: 10). This design note requires Dylan to
signal an error in such cases.
- #9: Punt Slot Descriptors (Change)
- This design note deletes Dylan's specification of slot descriptors.
This change removes a feature which is incomplete, which does not
match our current goals, and which impedes efficient implementation.
- #10: Element-Setter Signals Error (Clarification)
It is an error if element-setter cannot successfully set the element
of a sequence. This design note requires an error to be signaled in
that case, preventing programs from silently returning an incorrect
result or otherwise failing.
- #11: Last-Setter (Addition)
- This design note adds a specification for the generic function lastsetter, consistent with the setters for first, second, third, and
- #12: Size-Setter for Stretchy Sequences (Addition)
This design note adds the generic function size-setter to the
language specification, allowing the size of a stretchy sequence to
be changed in a single operation.
- #13: Type Restrictions Survive Assignment (Change)
When a parameter or local variable is specialized, its initial value
is required to be an instance of a certain type. This design note
extends the type restriction to cover values later stored into the
specialized parameter or local variable.
- #14: Union Allows Duplicates (Clarification)
- This design note clarifies that the result of union is only
guaranteed free of duplicates if no element appears more than once in
a single argument sequence. If the same element appears more than
once in a single argument sequence, it may appear more than once in
the result sequence. This allows union to be implemented more
- #15: Replace-Subsequence! Different Sizes (Change)
This design note extends the definition of replace-subsequence! to
allow the old and new subsequences to have different sizes. This
change greatly increases the utility of replace-subsequence!,
enabling it to be used for replace, insert and delete operations over
- #16: List Issues (Change)
- In this design note, Dylan's specification of the <list> type is made
more consistent with the rest of the language, mysterious
abbreviations and redundant list-only operations are removed, and
handling of improper lists is clarified. These changes make the
language more accessible to our primary audience of programmers who
have not used dynamic languages before.
- #17: Define Like Bind (Addition)
- This design note unifies the behavior of bind and define. It
extends define to support declaring the types of module variables
and defining multiple module variables from multiple values.
- #18: Member? Intersection Test Arg (Clarification)
This design note clarifies that the <range> methods for member? and
intersection support a test: keyword argument, which defaults to id?.
This makes the <range> methods consistent with the definitions for
these generic functions.
- #19: Definitions are Declarative (Change)
- This design note distinguishes definitions from other syntax forms,
making module variable definition essentially a declarative
operation, not a procedural one. Definitions are restricted to
appear only at the top level. A given module variable can only be
defined once, except for multiple define-method definitions with
different specializers. Definitions do not return values, since they
cannot appear as argument expressions.
- #20: New Syntax for Setter Variables (Change)
- This design note changes the syntax for setter variables. In the
revised syntax, the setter corresponding to the getter foo is named
foo-setter rather than (setter foo). This removes the special case
syntax for setters so that all variable names are symbols.
- #21: Result Type Declarations (Addition)
- This design note introduces a way to declare the result types of
methods and generic functions. This addition is intended to make
code more self-documenting and allow for better compiler
optimization. Type declarations will be checked at run time unless
they can be proven at compile time to be satisfied always.
- #22: BNF for Infix Dylan (Change)
This document presents a preliminary specification of the lexical and
syntactic aspects of Dylan.
- #23: Defining Forms Make Constants (Change)
This design note makes define-method more consistent with
define-generic-function. It also provides general declarative forms for
defining constants and variables.
- #24: Divide by Zero Signals Error (Clarification)
This design note specifies that division by zero signals an error. This
makes Dylan programs safer and more robust, possibly at the cost of speed
in some cases.
- #25: Exit Extent (Change)
Interactions between bind-exit and unwind-protect are complicated,
especially when a non-local exit is taken during the execution of an
unwind-protect cleanup form. This design note replaces bind-exit and
unwind-protect with a new block construct, and clarifies Dylan's
- #26: New Iteration Protocol (Change)
This Design Note specifies a revised iteration protocol for Dylan. The
new iteration protocol is complex, but allows better performance than the
original specification. Note that the iteration protocol is intended to
be used primarily by creators of new collection classes, rather than by
users of collections. In practice, most iterations will be hidden inside
for and the other standard iteration functions.
- #27: Pseudo-Generic Mappers (Change)
This design note changes the functions that iterate over an arbitrary
number of collections to be functions rather than generic functions. The
affected functions are: do, map, map-as, map-into, any?, every?,
concatenate, and concatenate-as.
- #28: First, Second, Third are Functions (Change)
The functions first, second, third, and their associated setter functions
are specified as generic functions on sequences. This design note
changes them to functions.
- #29: For Loops (Change)
This Design Note unifies Dylan's existing iteration constructs, for,
for-each, and dotimes, into one general for statement. It also changes
the keywords in <range> to be compatible with the numeric clauses in the
new for statement.
- #30: Make Range (Change)
This design note defines (make <range> ...) to create a range.
- #31: Method Specificity (Change)
This Design Note gives a revised specification of Dylan's handling of
- #32: Module Defining Forms (Addition)
This Design Note specifies a syntax and semantics for module defining
forms, which further documents the description of modules found in the
- #33: Headers for Dylan Source Files (Addition)
This design note specifies a standard portable format for distributing
Dylan source code.
- #34: Select Ordering (Clarification)
This design note specifies the order of evaluation for the select
- #35: Remove Transcendental Functions (Change)
This design note removes the functions sin, cos, tan, asin, acos, atan,
atan2, sinh, cosh, tanh, asinh, acosh, atanh, exp, log, and sqrt from
- #36: Remove Trivial Logical Operators (Change)
This design note removes the logical operators logeqv, lognand, lognor,
logandc1, logandc2, logorc1, and logorc2 from core Dylan.
- #37: Variadic Operators (Change)
The presence of separate binary and variadic versions of some functions
complicates the Dylan language. This design note removes several
variadic operators that are no longer needed in infix Dylan, and renames
the binary versions of those operators.
Next chapter: Design Note Format