DRM Errata

This page contains a listing of typos and other errors in the Dylan Reference Manual. If you find additional errors, please let us know at dylan-lang@googlegroups.com. Questions about Dylan, suggestions for improvements to the language, and general discussion should be directed to one of the communications channels listed on the opendylan.org community page.

This page was originally created by Andrew Shalit (and was extended by the Gwydion Dylan Maintainers later on). He writes:

Thanks go to Tom Emerson, for suggesting that I put together this page, and for supplying me with an initial list of typos.

Semantically Significant Errors

• p. 37 should include a horizontal rule immediately above the entry for :=. In other words, the precedence of := is lower than that of | and &.
• p. 43, in the example of multiple values with a rest-binding, a comma is missing between one and #rest.
• p. 69, the definition of class <person> is missing a comma between slot name and required-init-keyword:. The definition of class <astronaut> is missing commas in its keyword descriptors, between the keyword and init-value:.
• p. 73, the last paragraph explaining the subtype relationships of type-union reads

  subtype?(type-union*(s1...sm) type-union*(t1...tn))

  is missing a comma and should read

  subtype?(type-union*(s1...sm), type-union*(t1...tn))

• p. 73, the example code illustrating limited types reads

  limited(<integer> ,min: 0 max: 255)

  it should read

  limited(<integer>, min: 0, max: 255)

• p. 83, Closures. The second paragraph in this section talks about the score parameter, while the code actually uses a parameter called points.
• p. 93, in the second definition of method average, the return value declaration is incorrect; it contains both a binding name and a type

  => avg :: <number>;

  but the example is meant to illustrate how, if you do not provide both, the first word is parsed as the binding name even if it appears to be the name of a type. The return value declaration should read

  => <number>;

• p. 129, Instantiable Limited Collection Types. <deque> is missing from the list of instantiable limited collection types. There is a method specialized on <deque> in the list of methods for limited, below <stretchy-vector> on page 265, the discussion of which indicates that it is instantiable.
• p. 136, the illustration of the third constraint implied by define sealed domain should include open declarations for the initial classes and the generic function, as follows

  define open generic m ( x ) ;
  define open class <t> ( <object>) end class <t>;
  define open class <s> ( <object>) end class <s>;
  define method m ( s :: <s> ) end method m ;
  define sealed domain m ( <t> );
   
  define class <c> ( <s> , <t> ) end;

  In addition, the phrase, The definition of <c> would be valid if it appeared in the same library as the preceding definitions or in a library used by them… is not meant to imply that <c> could be defined in a library used by the library in which <t> and <s> are defined. This is clearly impossible because of the prohibition against circular library use paths. Rather, this phrase refers to the following possible scenario:

  Library L1
  define open class <t> ( .. ) ... end;
  define open class <s> ( .. ) ... end;

  L2 (uses L1)
  define class <c> (<s>, <t>) end;

  L3 (uses L1)
  define generic m (x);
  define method m (s :: <s>) ... end;
  define sealed domain m (<t>);

  These libraries can only be used together if L3 also uses (directly or indirectly) L2, and therefore has access to the class <c> before the domain is sealed.

• p. 140, the classes and generic function should be declared open.
• p. 140, the final method should be defined on <c1>, not on <c>.
• p. 198, the number classes diagram shows a <complex-number> class. This class is actually named <complex>.
• p. 207, the collection classes diagram has an arrow leading to various vector & string classes from <empty-list>. It should actually lead from <vector>.
• p. 224, the description of <stretchy-vector> says "the element type of <simple-vector>" where it should say "the element type of <stretchy-vector>."
• p. 263, the default value for the by argument to make of <range> should be 1, not 0.
• p. 309, in the example for tail-setter, the final value of x should be #(4 . "dot"), not #(4, 9, 8, . "dot").
• p. 325, in the description of replace-subsequence!, the parameter target-sequence is erroneously refered to as source-sequence in the last paragraph.
• p. 326, in the example calls of replace-subsequence!, each call ends with an extra right parenthesis.
• p. 329, in the example for map-as, the return value should be #[101, 102, 203, 204] rather than #(101, 102, 203, 204).
• p. 335, in the signature of find-key, the argument predicate is incorrectly named function.
• p. 341, in the example method definition of table-protocol, the method signature has two return values, so they should be in parentheses.
• p. 351, the second use of apply reads

  apply(min 5, 7 list(3, 1, 4))

  it should read

  apply(min, 5, 7, list(3, 1, 4))

  (Note the additional comma after the number 7 in the correct version.)

• p. 354, in the description of the third value returned by function-arguments, the obsolete binding name <keyword> is used. The name <symbol> should be substituted for the name <keyword>.
• p. 377, the use of the word permit in the last sentence describing the final example is incorrect. The word recognize should be used instead, yielding

  Methods added to the generic function must have one required parameter, they must accept keyword arguments, and they must recognize the keyword argument strength:.

  This change follows the definitions of the terms permit and recognize as given on page 94, in the description of parameter list congruency.

• p. 406, in the second code example of the block statement, the cleanup and exception clauses are incorrectly ordered. cleanup must come before exception clauses.

Simple Typos

• p. 42, the first occurrence of the two characters => should be a double-arrow ⇒.
• p. 44, the sentence describing execution order of operator calls reads

  The time of the binding specified by the operand (e.g. + or *) is unspecified.

  operand should be operator, yielding

  The time of the binding specified by the operator (e.g. + or *) is unspecified.

• p. 79, in this sentence about Generic Function signatures

  A generic function definition includes a parameter list, which constrains the methods that can be added to the generic function; some aspects of the parameter must be matched by any method added.

  the phrase …some aspects of the parameter must… should refer to the parameter list, i.e., …some aspects of the parameter list must be matched by any method added.
• p. 83, the two constant definitions should end with semicolons.
• p. 88, the sentence before the enumerated list reads

  Specialization is useful in three way:

  it is missing an s and should read

  Specialization is useful in three ways:

• p. 94, there should be a colon at the end of

  If the generic function's parameter list does not contain a rest value declaration, then

• p. 157, there should not be a space between fragment and (4).
• p. 165, line two includes a superfluous right parenthesis.
• p. 192, there's a missing period after There is no default in the description of init-function:.
• p. 203, the description of <extended-float> reads

  This class is intended but not required to provide more precision that <double-float>.

  that should be than, yielding

  This class is intended but not required to provide more precision than <double-float>.

• p. 219, the word When is misspelled Whe.
• p. 220, the first paragraph ends with two colons ::.
• p. 261, Tests whether a slot has been initialized is missing a period at the end of the sentence.
• p. 261, slot-initialized?, the description of the instance argument says, of of.
• p. 262, the signature of pair contains a comma between the two arguments.
• p. 288, the interactive example given for values contains a semicolon at the end of the input. This is unusual. See as on the following page for a comparison.
• p. 326, the examples calls of replace-subsequence! are missing double-arrows (⇒) at the start of the result lines.
• p. 344, the summary of all-superclasses reads

  Returns the class precedence list a class

  it is missing the word of and should read

  Returns the class precedence list of a class

• p. 382, the sentence fragment reading

  same binding to imported

  should read

  same binding to be imported

• p. 383, There should be a period at the end of the parenthetical sentence

  (There is no option to rename on export)

• p. 389, the sentence fragment reading

  so it cannot being excluded

  should read

  so it cannot be excluded

• p. 391, there should be a space between let and ( here:

  let(whole-part :: <integer>, remainder :: <real>) = truncate(amount);

• p. 393, the second paragraph begins

  The handler is function

  it is missing the word a and should read

  The handler is a function

• p. 400, the text ( test ) should not be in the until heading.
• p. 411, the word executation should be execution.
• p. 434, $permanent-hash-state has a leading space character (it shouldn't).
• p. 456, the index entry for define inert domain should be an entry for define sealed domain; inert was an early term for what later became known as sealed and is not used in the DRM.
• p. 461, the index entry for BNF of [lexical syntax] should capitalize BNF (it is written bnf of.)

Typesetting and Layout Errors

• p. 73, the first occurrence of x should be set in italic.
• p. 148, the parenthesis in the function-macro-call definition should be set in bold, as in the BNF appendix (A).
• p. 151, the commas and trailing spaces in ?, ??, and should be set in body font, not monospaced font.
• p. 160, in A reference to NAME, name should be set in small caps instead of regular capitals.
• p. 208, the <collection> heading should be set in monospaced font.
• p. 211, the <sequence> heading should be set in monospaced font.
• p. 245, the <condition> heading should be set in monospaced font.
• p. 247, the <serious-condition> heading should be set in monospaced font.
• p. 257-369, all of the identifier headings should be set in bold font, as done everywhere else, instead of normal weight.
• p. 289, the interactive examples given for as contain a space between function name and opening parenthesis. This is unusual. See values on the preceding page for a comparison. (Looking at it, there are lots of inconsistencies of this kind all around. Can we settle on the space-less form, uniformly?)
• p. 303, in array is modified by this operation., array should be in italics.
• p. 335, in the description of the member? method at the top of the page, the I of If is in Courier, and not the standard body font.
• p. 376, the define generic heading should be set in monospaced font.
• p. 389, the define macro heading should be set in monospaced font.
• p. 416, the backslashes \ before unary-operator and binary-operator should be set in bold.
• p. 416, the colon : after word should be set in normal, not italic.
• p. 418, the angle brackets < > around hex-digits should be set in bold.
• p. 420, there is a spurious vertical space above parsed-macro-call.
• p. 428, BNF ellipsis used instead of literal ellipsis in pattern-variable, see substitution (p. 429) for the correct one.