Dylan Design Notes

Introduction

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 programming language.

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 element.
#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 efficiently.
#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 any sequence.
#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 behavior.
#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 method specificity.
#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 Dylan book.
#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 statement.
#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 core Dylan.
#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