Previous chapter: Table of Contents

Dylan Design Notes: Design Note Format

Dylan Design Notes

Design Note Format

Each Design Note fits into one of the following categories:

The first section of each Design Note contains the following parts:

  1. the title of this Note
  2. the category that this Note fits into
  3. the version and date of this Design Note
  4. a one-paragraph summary of the clarification, change, or addition specified by this Note.
The second section of each Design Note contains the language specification itself. This may be expressed as a change to the text of the manual, or as an independent section. It often includes examples.

Some Design Notes have an additional section which may include implementation notes, further examples, or some of our reasons for making the change.

Throughout the Design Notes, the term parameter is used to mean formal parameter. That is, a parameter is a local variable bound upon entry to a function. The Design Notes use the term argument to describe what is sometimes called an actual parameter. That is, an argument is an object that is passed as the value of a parameter.

The names of parameters are often descriptive of the type of value acceptable as a value of the parameter. They will often match the names of classes, indicating a general instance of the class. For example, number indicates a general instance of the class <number>, and string indicates a general instance of the class <string>.

The following notation is used to describe syntax forms:

        {...}      Curly braces indicate a group of items.

        {...}*     Curly braces followed by an asterisk indicate that the 
                   contents can appear zero or more times.

        {...}+     Curly braces followed by a plus sign indicate that the 
                   contents can appear one or more times.

        [...]      Square brackets indicate that the contents are optional.

        ... | ...  Items separated by a vertical bar are mutually exclusive.  
                   One or the other may appear.
We issue the Design Notes in plain text format as well as in PostScript. In the PostScript format, we use a small number of typographic conventions to enhance readability: The error messages in the Design Notes have been edited for brevity. The details of interactions with Dylan (prompt text, error message texts, etc.) may differ among implementations.


Dylan Correspondence

Questions and comments about Dylan may be sent to:
        info-dylan@cambridge.apple.com 
and will appear on the info-dylan mailing list. Private correspondence may be sent to:
        dylan-comments@cambridge.apple.com.
To subscribe to the info-dylan mailing list, send a message to:
        info-dylan-request@cambridge.apple.com
The body of the message should read:
        subscribe info-dylan
The info-dylan mailing list is also available in a digest format. The digest is put together and mailed out every morning at 4AM and covers all the mail received by the list in the last 24 hours. To subscribe to the digest, send a message to:
        info-dylan-digest-request@cambridge.apple.com
The body of the message should read:
        subscribe info-dylan-digest
If you prefer to read info-dylan as a Usenet newsgroup, it is available under the name comp.lang.dylan.

To access the current Dylan FAQ, archived Dylan Design Notes, and other archived Dylan information, connect by anonymous ftp to cambridge.apple.com. Dylan information is located in the /pub/dylan directory.

Next chapter: #1: Collection Class-For-Copy (Clarification)