Dylan Design Notes

Copyright (c) 1993-1994, Apple Computer

-------------------------------------------------------------------

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.

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.

-------------------------------------------------------------------

Design Note Format

Each Design Note fits into one of the following categories:
        clarification	This Design Note resolves an ambiguity or 
			underspecification in the Dylan manual.
        change	        This Design Note specifies an incompatible 
			change.
        addition	This Design Note specifies a compatible 
			extension.

The first section of each Design Note contains the following parts: 
        the title of this Note,
        the category that this Note fits into,
        the version and date of this Design Note,
	and 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:

        Body text appears in Roman.

        First uses of terms appear in Bold.

        Text which appears as it would be entered in the computer
	appears	in Courier.

        Formal parameters appear in Italic.

        Interactions between a user and a Dylan listener are shown in
	a mixture of Courier and Courier Oblique.  Courier shows
	the text entered by the user, and Courier Oblique shows the
	text printed by the listener.  The question mark used in these
	sections is the listener's prompt.

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.

        A text-only version of the Dylan FAQ is in dylan-faq.txt.  A 
	binhex MS Word version of the Dylan FAQ is in dylan-faq.msword.hqx.

        The Dylan Design Notes are archived in the design-notes 
	directory.  Within the design-notes directory, text-only files
	are in the text subdirectory, and postscript files are in the
	postscript subdirectory.
