Author: cpage
Date: Mon Dec 19 00:04:11 2005
New Revision: 10411
Modified:
trunk/www/books/drm/Arithmetic_Operations.html
trunk/www/books/drm/Assignment.html
trunk/www/books/drm/Auxiliary_Rule_Sets.html
trunk/www/books/drm/BNF.html
trunk/www/books/drm/Background_and_Goals.html
trunk/www/books/drm/Bindings.html
trunk/www/books/drm/Bodies.html
trunk/www/books/drm/Built-In_Classes_Overview.html
trunk/www/books/drm/Built-In_Functions_Overview.html
trunk/www/books/drm/Built-In_Macros_and_Special_Definitions_Overview.html
trunk/www/books/drm/Classes.html
trunk/www/books/drm/Coercing_and_Copying_Objects.html
trunk/www/books/drm/Collection_Alignment.html
trunk/www/books/drm/Collection_Alteration_and_Allocation.html
trunk/www/books/drm/Collection_Classes.html
trunk/www/books/drm/Collection_Keys.html
trunk/www/books/drm/Collection_Operations.html
trunk/www/books/drm/Collections_Overview.html
trunk/www/books/drm/Colophon.html
trunk/www/books/drm/Condition_Messages.html
trunk/www/books/drm/Conditional_Execution.html
trunk/www/books/drm/Conditions_Background.html
trunk/www/books/drm/Conditions_Overview.html
trunk/www/books/drm/Constructing_and_Initializing_Instances.html
trunk/www/books/drm/Declaring_Characteristics_of_Classes.html
trunk/www/books/drm/Declaring_Characteristics_of_Generic_Functions.html
trunk/www/books/drm/Define_Sealed_Domain.html
trunk/www/books/drm/Defining_a_New_Collection_Class.html
trunk/www/books/drm/Definition_Macros.html
trunk/www/books/drm/Definitions.html
trunk/www/books/drm/Dylan_Interchange_Format.html
trunk/www/books/drm/Element_Types.html
trunk/www/books/drm/Equality_and_Comparison.html
trunk/www/books/drm/Exception_Handling.html
trunk/www/books/drm/Exported_Names.html
trunk/www/books/drm/Expressions.html
trunk/www/books/drm/Extensible_Grammar.html
trunk/www/books/drm/Function_Calls.html
trunk/www/books/drm/Function_Classes.html
trunk/www/books/drm/Function_Macros.html
trunk/www/books/drm/Functional_Operations.html
trunk/www/books/drm/Functions_Overview.html
trunk/www/books/drm/Hygiene.html
trunk/www/books/drm/Instance_Creation_and_Initialization.html
trunk/www/books/drm/Introspective_Operations_on_Conditions.html
trunk/www/books/drm/Iteration.html
trunk/www/books/drm/Iteration_Stability_and_Natural_Order.html
trunk/www/books/drm/Language_Overview.html
trunk/www/books/drm/Lexical_Grammar.html
trunk/www/books/drm/Lexical_Syntax.html
trunk/www/books/drm/Libraries.html
trunk/www/books/drm/Libraries_and_Modules.html
trunk/www/books/drm/Limited_Collection_Types.html
trunk/www/books/drm/Limited_Types.html
trunk/www/books/drm/Local_Declaration_Macros.html
trunk/www/books/drm/Local_Declarations.html
trunk/www/books/drm/Macro_Names.html
trunk/www/books/drm/Macros_Overview.html
trunk/www/books/drm/Macros_Syntax.html
trunk/www/books/drm/Manual_Notation.html
trunk/www/books/drm/Method_Dispatch.html
trunk/www/books/drm/Modules.html
trunk/www/books/drm/Multiple_Values.html
trunk/www/books/drm/Mutability.html
trunk/www/books/drm/Naming_Conventions.html
trunk/www/books/drm/Nonlocal_Exits_and_Cleanup_Clauses.html
trunk/www/books/drm/Number_Classes.html
trunk/www/books/drm/Operations_on_Conditions.html
trunk/www/books/drm/Operations_on_Functions.html
trunk/www/books/drm/Operators.html
trunk/www/books/drm/Order_of_Execution.html
trunk/www/books/drm/Other_Built-In_Objects_Defined.html
trunk/www/books/drm/Parameter_Lists.html
trunk/www/books/drm/Parameter_Lists_Syntax.html
trunk/www/books/drm/Pattern_Variable_Constraints.html
trunk/www/books/drm/Patterns.html
trunk/www/books/drm/Preface.html
trunk/www/books/drm/Program_Control_Overview.html
trunk/www/books/drm/Reflective_Operations_on_Functions.html
trunk/www/books/drm/Reflective_Operations_on_Types.html
trunk/www/books/drm/Rewrite_Rule_Examples.html
trunk/www/books/drm/Rewrite_Rules.html
trunk/www/books/drm/Sealing_Overview.html
trunk/www/books/drm/Signalers_Conditions_and_Handlers.html
trunk/www/books/drm/Simple_Object_Classes.html
trunk/www/books/drm/Singletons.html
trunk/www/books/drm/Slots.html
trunk/www/books/drm/Special_Treatment_of_Names.html
trunk/www/books/drm/Statement_Macros.html
trunk/www/books/drm/Statements.html
trunk/www/books/drm/Syntax_Overview.html
trunk/www/books/drm/Tables.html
trunk/www/books/drm/Templates.html
trunk/www/books/drm/Top-Level_Definitions.html
trunk/www/books/drm/Type_Classes.html
trunk/www/books/drm/Type_Protocol.html
trunk/www/books/drm/Types_and_Classes_Overview.html
trunk/www/books/drm/Union_Types.html
Log:
Job: website
Removed the redundant class T1.Text1. Nearly every paragraph P tag had this
class, making it the default and therefore unnecessary.
Modified: trunk/www/books/drm/Arithmetic_Operations.html
==============================================================================
--- trunk/www/books/drm/Arithmetic_Operations.html (original)
+++ trunk/www/books/drm/Arithmetic_Operations.html Mon Dec 19 00:04:11 2005
@@ -323,7 +323,7 @@
<a name="HEADING100-21"></a>
<h5 class="method-signature"><span class="signature"><code>zero?
<var>complex</var> </code>
⇒<code> <var>boolean</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A method is defined for the class
<code><complex></code>.</p>
+ <p>A method is defined for the class <code><complex></code>.</p>
</dd>
</dl>
<a name="HEADING100-23"></a>
@@ -361,7 +361,7 @@
<a name="HEADING100-29"></a>
<h5 class="method-signature"><span class="signature"><code>positive?
<var>real</var> </code>
⇒<code> <var>boolean</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A method is defined for the class
<code><real></code>.</p>
+ <p>A method is defined for the class <code><real></code>.</p>
</dd>
</dl>
<a name="HEADING100-31"></a>
@@ -399,7 +399,7 @@
<a name="HEADING100-37"></a>
<h5 class="method-signature"><span class="signature"><code>negative?
<var>real</var> </code>
⇒<code> <var>boolean</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A method is defined for the class
<code><real></code>.</p>
+ <p>A method is defined for the class <code><real></code>.</p>
</dd>
</dl>
<a name="HEADING100-39"></a>
@@ -437,12 +437,12 @@
<a name="HEADING100-45"></a>
<h5 class="method-signature"><span class="signature"><code>integral?
<var>object</var> </code>
⇒<code> <var>false</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">A method is defined for the class
<code><object></code> that
+ <p>A method is defined for the class <code><object></code> that
returns <code>#f</code>.</p>
<a name="HEADING100-47"></a>
<h5 class="method-signature"><span class="signature"><code>integral?
<var>real</var> </code>
⇒<code> <var>boolean</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A method is defined for real numbers that is
equivalent to <code><var>real</var> =
+ <p>A method is defined for real numbers that is equivalent to
<code><var>real</var> =
round(<var>real</var>)</code>.<a name="MARKER-2-1617"></a></p>
</dd>
</dl>
@@ -485,7 +485,7 @@
<a name="HEADING100-57"></a>
<h5 class="method-signature"><span
class="signature"><code><var>complex1</var> + <var>complex2</var> </code>
⇒<code> <var>complex</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the sum of two
complex numbers.</p>
+ <p>A predefined method returns the sum of two complex numbers.</p>
</dd>
</dl>
<a name="HEADING100-59"></a>
@@ -524,7 +524,7 @@
<a name="HEADING100-66"></a>
<h5 class="method-signature"><span
class="signature"><code><var>complex1</var> * <var>complex2</var> </code>
⇒<code> <var>complex</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the product of two
complex numbers.</p>
+ <p>A predefined method returns the product of two complex numbers.</p>
</dd>
</dl>
<a name="HEADING100-68"></a>
@@ -563,7 +563,7 @@
<a name="HEADING100-75"></a>
<h5 class="method-signature"><span
class="signature"><code><var>complex1</var> - <var>complex2</var> </code>
⇒<code> <var>complex</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the difference of two
complex numbers.</p>
+ <p>A predefined method returns the difference of two complex
numbers.</p>
</dd>
</dl>
<a name="HEADING100-77"></a>
@@ -602,9 +602,9 @@
<a name="HEADING100-84"></a>
<h5 class="method-signature"><span
class="signature"><code><var>complex1</var> / <var>complex2</var> </code>
⇒<code> <var>complex</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the quotient of two
complex numbers.</p>
- <p class="T1.Text1"><a name="MARKER-2-1626"></a><a
name="MARKER-2-1627"></a>Division by zero signals an error.</p>
- <p class="T1.Text1">The result of dividing two integers with / is
implementation defined. Portable programs should use <code>floor/</code>,
<code>ceiling/</code>, <code>round/</code>, or <code>truncate/</code> to divide
two integers.</p>
+ <p>A predefined method returns the quotient of two complex
numbers.</p>
+ <p><a name="MARKER-2-1626"></a><a name="MARKER-2-1627"></a>Division
by zero signals an error.</p>
+ <p>The result of dividing two integers with / is implementation
defined. Portable programs should use <code>floor/</code>,
<code>ceiling/</code>, <code>round/</code>, or <code>truncate/</code> to divide
two integers.</p>
</dd>
</dl>
<a name="HEADING100-88"></a>
@@ -642,7 +642,7 @@
<a name="HEADING100-94"></a>
<h5 class="method-signature"><span class="signature"><code>negative
<var>real1</var> </code>
⇒<code> <var>real2</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the additive inverse
of a real number.</p>
+ <p>A predefined method returns the additive inverse of a real
number.</p>
</dd>
</dl>
<a name="HEADING100-96"></a>
@@ -1025,7 +1025,7 @@
<a name="HEADING100-177"></a>
<h5 class="method-signature"><span
class="signature"><code><var>complex</var> ^ <var>integer</var> </code>
⇒<code><var>number</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method raises a complex number to an
integral power and returns the result.</p>
+ <p>A predefined method raises a complex number to an integral power
and returns the result.</p>
</dd>
</dl>
<a name="HEADING100-179"></a>
@@ -1063,7 +1063,7 @@
<a name="HEADING100-185"></a>
<h5 class="method-signature"><span class="signature"><code>abs
<var>complex</var> </code>
⇒<code> <var>real</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the absolute value of
a complex number.</p>
+ <p>A predefined method returns the absolute value of a complex
number.</p>
</dd>
</dl>
<a name="HEADING100-187"></a>
@@ -1231,7 +1231,7 @@
</dd>
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche"><p>Returns true if the <var>index</var>th bit in
<var>integer</var> is a one-bit; otherwise it returns false.</p>
- <p class="T1.Text1">Negative <var>integers</var> are treated as if
they were in two's-complement notation.</p></dd>
+ <p>Negative <var>integers</var> are treated as if they were in
two's-complement notation.</p></dd>
</dl>
<a name="HEADING100-219"></a>
<h4 class="item-title"><span class="signature"><code
id="MARKER-2-1666">ash</code> </span><span
class="attributes-summary">[Function]</span></h4>
@@ -1267,14 +1267,14 @@
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche">
<p>Performs an arithmetic shift on the binary representation of
<var>integer1</var>.</p>
- <p class="T1.Text1"><code>ash</code> shifts <var>integer1</var>
arithmetically left
- by <var>count</var> bit positions if <var>count</var> is positive, or
- right <var>count</var> bit positions if <var>count</var> is negative.
The shifted value of
- the same sign as <var>integer1</var> is returned.</p>
- <p class="T1.Text1">When <code>ash</code> moves bits to the left, it
adds zero-bits at the
- right. When it moves them to the right, it discards bits.</p>
- <p class="T1.Text1"><code>ash</code> is defined to behave as if
<var>integer1</var> were
- represented in two's complement form, regardless of how integers are
represented by the
+ <p><code>ash</code> shifts <var>integer1</var> arithmetically left by
<var>count</var> bit
+ positions if <var>count</var> is positive, or right <var>count</var>
bit positions
+ if <var>count</var> is negative. The shifted value of the same sign
as <var>integer1</var>
+ is returned.</p>
+ <p>When <code>ash</code> moves bits to the left, it adds zero-bits at
the right. When it
+ moves them to the right, it discards bits.</p>
+ <p><code>ash</code> is defined to behave as if <var>integer1</var>
were represented in
+ two's complement form, regardless of how integers are represented by
the
implementation.</p>
<pre class="code">
ash(8, 1)
@@ -1321,7 +1321,7 @@
<a name="HEADING100-237"></a>
<h5 class="method-signature"><span class="signature"><code>lcm
<var>integer1 integer2</var> </code>
⇒<code> <var>integer3</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the least common
multiple of two integers.</p>
+ <p>A predefined method returns the least common multiple of two
integers.</p>
</dd>
</dl>
<a name="HEADING100-239"></a>
@@ -1360,7 +1360,7 @@
<a name="HEADING100-246"></a>
<h5 class="method-signature"><span class="signature"><code>gcd
<var>integer1 integer2</var> </code>
⇒<code> <var>integer3</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">A predefined method returns the greatest common
divisor of two integers.<a name="MARKER-2-1673"></a></p>
+ <p>A predefined method returns the greatest common divisor of two
integers.<a name="MARKER-2-1673"></a></p>
</dd>
</dl>
Modified: trunk/www/books/drm/Assignment.html
==============================================================================
--- trunk/www/books/drm/Assignment.html (original)
+++ trunk/www/books/drm/Assignment.html Mon Dec 19 00:04:11 2005
@@ -118,9 +118,9 @@
<a name="HEADING32-0"></a>
<a name="UID-Program_Control-1200"></a>
<h1 class="section-title"><a name="MARKER-2-451"></a>Assignment</h1>
-<p class="T1.Text1"><a name="MARKER-2-452"></a>The operator <code>:=
</code>is used to set variables to new values and as an alternate syntax for
calling setter functions and macros.</p>
-<p class="T1.Text1">The assignment operator is described in detail on <a
href="Function_Macros#MARKER-9-2072">page 409</a>.</p>
-<p class="T1.Text1"><a name="MARKER-2-453"></a>The following examples show the
use of <code>:=</code> to change the value of a module binding.</p>
+<p><a name="MARKER-2-452"></a>The operator <code>:= </code>is used to set
variables to new values and as an alternate syntax for calling setter functions
and macros.</p>
+<p>The assignment operator is described in detail on <a
href="Function_Macros#MARKER-9-2072">page 409</a>.</p>
+<p><a name="MARKER-2-453"></a>The following examples show the use of
<code>:=</code> to change the value of a module binding.</p>
<pre class="code">
define variable *foo* = 10;
*foo*
@@ -130,7 +130,7 @@
*foo*
<code> ⇒</code> 110
</pre>
-<p class="T1.Text1"><a name="MARKER-2-454"></a><a name="MARKER-2-455"></a>The
following examples show the use of <code>:=</code> as shorthand for calling a
setter function. In general, using this syntax to call a function
<var>fun</var> is equivalent to calling the function
<code><var>fun</var>-setter</code>.</p>
+<p><a name="MARKER-2-454"></a><a name="MARKER-2-455"></a>The following
examples show the use of <code>:=</code> as shorthand for calling a setter
function. In general, using this syntax to call a function <var>fun</var> is
equivalent to calling the function <code><var>fun</var>-setter</code>.</p>
<pre class="code">
define variable *foo* = vector (10, 6, 8, 5);
element(*foo*, 2)
@@ -140,12 +140,12 @@
*foo*
<code> ⇒</code> #[10, 6, "bar", 5]
</pre>
-<p class="T1.Text1">The following examples show the use of <code>:=</code> as
shorthand for calling a setter function using slot access notation.</p>
+<p>The following examples show the use of <code>:=</code> as shorthand for
calling a setter function using slot access notation.</p>
<pre class="code">
window.position := point(100, 100)
vector.size := 50
</pre>
-<p class="T1.Text1">The following examples show the use of <code>:=</code> as
shorthand for calling <code id="MARKER-2-456">element-setter</code> or <code
id="MARKER-2-457">aref-setter</code>.</p>
+<p>The following examples show the use of <code>:=</code> as shorthand for
calling <code id="MARKER-2-456">element-setter</code> or <code
id="MARKER-2-457">aref-setter</code>.</p>
<pre class="code">
my-vector[2] := #"two"
my-array[1,1] := #"top-left"<a name="MARKER-2-458"></a>
Modified: trunk/www/books/drm/Auxiliary_Rule_Sets.html
==============================================================================
--- trunk/www/books/drm/Auxiliary_Rule_Sets.html (original)
+++ trunk/www/books/drm/Auxiliary_Rule_Sets.html Mon Dec 19 00:04:11 2005
@@ -119,12 +119,12 @@
<a name="HEADING84-0"></a>
<a name="UID-Macros-1862"></a>
<h1 class="section-title">Auxiliary Rule Sets</h1>
-<p class="T1.Text1"><a name="MARKER-2-1265"></a>Auxiliary rule sets are like
<a name="MARKER-2-1266"></a>subroutines for rewrite rules. An auxiliary rule
set rewrites the value of a pattern variable after it is bound by a pattern and
before it is substituted into a template. Auxiliary rule sets only come into
play after a pattern has matched; the failure of all patterns in an auxiliary
rule set to match causes the entire macro call to be declared invalid, rather
than back-tracking and trying the next pattern in the calling rule set.</p>
-<p class="T1.Text1">See the definition of <var>aux-rule-sets</var> in <a
href="Phrase_Grammar#MARKER-9-2122">"Auxiliary Rule Sets" on page 430</a>.</p>
-<p class="T1.Text1">A <em class="BNFCaps">symbol</em> flags the beginning of
an auxiliary rule set. For readability it is generally written as
<code>name:</code> rather than <code>#"name"</code>. The name of the
symbol is the same as the name of the pattern variable that is rewritten by
this auxiliary rule set. All occurrences of this pattern variable in all rule
sets are rewritten. A pattern variable can occur in the very auxiliary rule set
that rewrites that pattern variable; this is how you write recursive rewrite
rules, which greatly expand the power of pattern-matching.</p>
-<p class="T1.Text1">When an auxiliary rule set's pattern variable occurs in a
double question-mark <var>pattern-keyword</var>, the auxiliary rule set
rewrites each property value in the sequence individually.</p>
-<p class="T1.Text1">The order of auxiliary rule sets in a macro definition is
immaterial.</p>
-<p class="T1.Text1">The ellipsis <code>...</code> in patterns and templates of
an auxiliary rule set means exactly the same thing as the pattern variable that
is rewritten by this auxiliary rule set. Using ellipsis instead of the pattern
variable can make recursive rewrite rules more readable.<a
name="MARKER-2-1267"></a></p>
+<p><a name="MARKER-2-1265"></a>Auxiliary rule sets are like <a
name="MARKER-2-1266"></a>subroutines for rewrite rules. An auxiliary rule set
rewrites the value of a pattern variable after it is bound by a pattern and
before it is substituted into a template. Auxiliary rule sets only come into
play after a pattern has matched; the failure of all patterns in an auxiliary
rule set to match causes the entire macro call to be declared invalid, rather
than back-tracking and trying the next pattern in the calling rule set.</p>
+<p>See the definition of <var>aux-rule-sets</var> in <a
href="Phrase_Grammar#MARKER-9-2122">"Auxiliary Rule Sets" on page 430</a>.</p>
+<p>A <em class="BNFCaps">symbol</em> flags the beginning of an auxiliary rule
set. For readability it is generally written as <code>name:</code> rather than
<code>#"name"</code>. The name of the symbol is the same as the name
of the pattern variable that is rewritten by this auxiliary rule set. All
occurrences of this pattern variable in all rule sets are rewritten. A pattern
variable can occur in the very auxiliary rule set that rewrites that pattern
variable; this is how you write recursive rewrite rules, which greatly expand
the power of pattern-matching.</p>
+<p>When an auxiliary rule set's pattern variable occurs in a double
question-mark <var>pattern-keyword</var>, the auxiliary rule set rewrites each
property value in the sequence individually.</p>
+<p>The order of auxiliary rule sets in a macro definition is immaterial.</p>
+<p>The ellipsis <code>...</code> in patterns and templates of an auxiliary
rule set means exactly the same thing as the pattern variable that is rewritten
by this auxiliary rule set. Using ellipsis instead of the pattern variable can
make recursive rewrite rules more readable.<a name="MARKER-2-1267"></a></p>
</div>
Modified: trunk/www/books/drm/BNF.html
==============================================================================
--- trunk/www/books/drm/BNF.html (original)
+++ trunk/www/books/drm/BNF.html Mon Dec 19 00:04:11 2005
@@ -121,10 +121,10 @@
<h1 class="appendix-title"><a name="MARKER-9-2090"></a>BNF</h1>
<a name="HEADING116-1"></a>
<h2 class="subsection-title">General Notes</h2>
- <p class="T1.Text1">Dylan <a name="MARKER-2-2091"></a>syntax can be
parsed with
+ <p>Dylan <a name="MARKER-2-2091"></a>syntax can be parsed with
an <a name="MARKER-2-2092"></a>LALR(1) <a
name="MARKER-2-2093"></a>grammar.</p>
- <p class="T1.Text1"><a name="MARKER-2-2094"></a>This appendix uses some
special notation to
- make the presentation of the grammar more readable.</p>
+ <p><a name="MARKER-2-2094"></a>This appendix uses some special notation
to make the
+ presentation of the grammar more readable.</p>
<ul>
<li>The <sub class="BNF"><i>opt</i></sub> suffix means that the
preceding item is
optional.</li>
@@ -144,8 +144,8 @@
<li>The grammar does not use distinct identifiers for grammar rules
that differ only in
alphabetic case.</li>
</ul>
- <p class="T1.Text1">In the following grammar, some tokens are used
multiple ways. For example
- the hyphen, "<code>-</code>," is punctuation, a unary operator, and a
binary operator; also,
+ <p>In the following grammar, some tokens are used multiple ways. For
example the hyphen,
+ "<code>-</code>," is punctuation, a unary operator, and a binary
operator; also,
"<code>method</code>" is a <em class="BNFCaps">begin-word</em> and
a <em class="BNFCaps">define-body-word</em>. In some parsing
implementations such multiple
meanings of a token may not be possible. However this is just an
implementation issue since
@@ -159,14 +159,14 @@
transformations implemented by most parser generators.</p>
<a name="HEADING116-11"></a>
<h2 class="subsection-title"><a name="MARKER-2-2095"></a>Lexical
Notes</h2>
- <p class="T1.Text1">In the lexical grammar, the various elements that
come together to form a
- single token on the right-hand sides of rules must <var>not</var> be
separated by whitespace,
- so that the end result will be a single token. This is in contrast to
the phrase grammar,
- where each element is already a complete token or a series of complete
tokens.</p>
- <p class="T1.Text1">Arbitrary whitespace is permitted between tokens,
but it is required only
- as necessary to separate tokens that might otherwise blend together.</p>
- <p class="T1.Text1">Case is not significant except within character and
string literals. The
- grammars do not reflect this, using one case or the other, but it is
still true.</p>
+ <p>In the lexical grammar, the various elements that come together to
form a single token on
+ the right-hand sides of rules must <var>not</var> be separated by
whitespace, so that the end
+ result will be a single token. This is in contrast to the phrase
grammar, where each element
+ is already a complete token or a series of complete tokens.</p>
+ <p>Arbitrary whitespace is permitted between tokens, but it is required
only as necessary to
+ separate tokens that might otherwise blend together.</p>
+ <p>Case is not significant except within character and string literals.
The grammars do not
+ reflect this, using one case or the other, but it is still true.</p>
</div>
Modified: trunk/www/books/drm/Background_and_Goals.html
==============================================================================
--- trunk/www/books/drm/Background_and_Goals.html (original)
+++ trunk/www/books/drm/Background_and_Goals.html Mon Dec 19 00:04:11 2005
@@ -112,13 +112,13 @@
<a name="HEADING6-0"></a>
<a name="UID-Introduction-2118"></a>
<h1 class="section-title"><a name="MARKER-2-169"></a>Background and Goals</h1>
-<p class="T1.Text1">Dylan is a general-purpose, high-level programming
language, designed for use in application and systems programming. Dylan
includes garbage collection, type-safety, error recovery, a module system, and
programmer control over runtime extensibility of programs.</p>
-<p class="T1.Text1">The name "Dylan" is a portmanteau of the words "dynamic"
and "language." Dylan is designed to allow efficient, static compilation of
features normally associated with dynamic languages.</p>
-<p class="T1.Text1">Dylan was created out of the belief that programs have
become too complex for traditional static programming languages. A new
generation of software — software that can be built quickly and enhanced
over time — requires higher-level programming tools. The core of these
tools is a simple and expressive language, one that protects the programmer
from low-level implementation details, but still produces efficient
executables.</p>
-<p class="T1.Text1">Dylan was designed from the ground up with a thoroughly
integrated object model, syntax, and control structures. It is not source code
compatible with any existing languages, and can therefore be more internally
self-consistent. At the same time, Dylan's syntax and object-model allow a
high-level of integration with libraries written in other languages such as C
and C++.</p>
-<p class="T1.Text1">Dylan avoids providing multiple ways of doing the same
thing. Quite the opposite, the language often uses a single construct to
achieve several ends. For example, Dylan's type declarations improve the
efficiency and readability of programs, they ensure type safety, and they
provide the basis of polymorphic dispatch, the basic mechanism of
object-oriented flow of control.</p>
-<p class="T1.Text1">And while simplicity of language is very important, it
should not and need not come at the price of expressiveness. Multi-method
dispatch is an example of a Dylan feature that makes the language more powerful
and simultaneously makes Dylan programs easier to understand.</p>
-<p class="T1.Text1">Dylan demonstrates that a programming language can be
highly expressive, can encourage the use of appropriate abstraction, can make
programming more productive, and can make the programming process enjoyable,
all without sacrificing the ability to compile into code that is very close to
the machine, and therefore very efficient.</p>
+<p>Dylan is a general-purpose, high-level programming language, designed for
use in application and systems programming. Dylan includes garbage collection,
type-safety, error recovery, a module system, and programmer control over
runtime extensibility of programs.</p>
+<p>The name "Dylan" is a portmanteau of the words "dynamic" and "language."
Dylan is designed to allow efficient, static compilation of features normally
associated with dynamic languages.</p>
+<p>Dylan was created out of the belief that programs have become too complex
for traditional static programming languages. A new generation of software
— software that can be built quickly and enhanced over time —
requires higher-level programming tools. The core of these tools is a simple
and expressive language, one that protects the programmer from low-level
implementation details, but still produces efficient executables.</p>
+<p>Dylan was designed from the ground up with a thoroughly integrated object
model, syntax, and control structures. It is not source code compatible with
any existing languages, and can therefore be more internally self-consistent.
At the same time, Dylan's syntax and object-model allow a high-level of
integration with libraries written in other languages such as C and C++.</p>
+<p>Dylan avoids providing multiple ways of doing the same thing. Quite the
opposite, the language often uses a single construct to achieve several ends.
For example, Dylan's type declarations improve the efficiency and readability
of programs, they ensure type safety, and they provide the basis of polymorphic
dispatch, the basic mechanism of object-oriented flow of control.</p>
+<p>And while simplicity of language is very important, it should not and need
not come at the price of expressiveness. Multi-method dispatch is an example of
a Dylan feature that makes the language more powerful and simultaneously makes
Dylan programs easier to understand.</p>
+<p>Dylan demonstrates that a programming language can be highly expressive,
can encourage the use of appropriate abstraction, can make programming more
productive, and can make the programming process enjoyable, all without
sacrificing the ability to compile into code that is very close to the machine,
and therefore very efficient.</p>
</div>
Modified: trunk/www/books/drm/Bindings.html
==============================================================================
--- trunk/www/books/drm/Bindings.html (original)
+++ trunk/www/books/drm/Bindings.html Mon Dec 19 00:04:11 2005
@@ -124,16 +124,16 @@
<a name="HEADING12-0"></a>
<a name="UID-Syntax-1434"></a>
<h1 class="section-title">Bindings</h1>
- <p class="T1.Text1">A <dfn id="MARKER-2-225">binding</dfn> is an
association of a name with a
+ <p>A <dfn id="MARKER-2-225">binding</dfn> is an association of a name
with a
value. The bindings in a module persist for the life of the program
execution. The scope of
such a binding is its module. That is, the binding is visible to all
source-records in the
module. A module can export bindings and can import bindings from other
modules. Only an
exported binding can be imported. A binding is visible to all
source-records in a module that
imports it.</p>
- <p class="T1.Text1">A binding may be <dfn
id="MARKER-2-226">specialized</dfn>. This restricts
+ <p>A binding may be <dfn id="MARKER-2-226">specialized</dfn>. This
restricts
the types of values that may be held in the binding. An error will be
signaled on any attempt
to initialize or assign the binding to a value that is not of the
correct type.</p>
- <p class="T1.Text1">A binding is either <dfn
id="MARKER-2-227">constant</dfn>
+ <p>A binding is either <dfn id="MARKER-2-227">constant</dfn>
or <dfn id="MARKER-2-228">variable</dfn>. A constant
(or <a name="MARKER-2-229"></a>read-only) binding always has the same
value. In contrast, a
variable (or writable) binding can have its value changed, using the
assignment
Modified: trunk/www/books/drm/Bodies.html
==============================================================================
--- trunk/www/books/drm/Bodies.html (original)
+++ trunk/www/books/drm/Bodies.html Mon Dec 19 00:04:11 2005
@@ -124,12 +124,12 @@
<a name="HEADING14-0"></a>
<a name="UID-Syntax-1441"></a>
<h1 class="section-title">Bodies</h1>
- <p class="T1.Text1">A <dfn id="MARKER-2-232">body</dfn> is a sequence of
zero or more
+ <p>A <dfn id="MARKER-2-232">body</dfn> is a sequence of zero or more
constituents. When multiple constituents are present, they are separated
by semicolons. When
at least one constituent is present, the last constituent can optionally
be followed by a
semicolon; this allows programmers to regard the semicolon as either a
terminator or a
separator, according to their preferred programming style.</p>
- <p class="T1.Text1">A <dfn id="MARKER-2-233">constituent</dfn> is either
a definition, a local
+ <p>A <dfn id="MARKER-2-233">constituent</dfn> is either a definition, a
local
declaration, or an expression. Definitions and local declarations form
the structure of a
program and do not return values. In contrast, expressions are executed
for the values they
return and/or the side-effects that they perform.</p>
Modified: trunk/www/books/drm/Built-In_Classes_Overview.html
==============================================================================
--- trunk/www/books/drm/Built-In_Classes_Overview.html (original)
+++ trunk/www/books/drm/Built-In_Classes_Overview.html Mon Dec 19 00:04:11 2005
@@ -118,10 +118,10 @@
<a name="UID-Built-In_Classes-12650"></a>
<h1 class="section-title">Overview</h1>
<p class="T0.Text0"><a name="MARKER-2-1360"></a>This chapter contains an entry
for every class defined by Dylan.</p>
-<p class="T1.Text1">The superclasses listed for a class <var>C</var> are those
classes defined by the Dylan language from which <var>C</var> most directly
inherits. They are not required to be the direct superclasses of <var>C</var>,
because implementations are free to insert implementation-defined classes in
the class hierarchy. However, any classes defined by Dylan that appear in the
class precedence list of <var>C</var> must appear in the same order in which
they would appear if the specified superclasses were the direct superclasses of
<var>C</var>, in the order given.</p>
-<p class="T1.Text1">All classes are specified as open or sealed. A class may
be specifed as abstract; if it is not, then it is concrete. A class may be
specified as primary; if it is not, than it is free. A class may be specified
as instantiable. If it is not, then it is uninstantiable. <a
href="Sealing">Chapter 9, "Sealing,"</a> contains a complete description of
these characteristics.</p>
-<p class="T1.Text1"><a name="MARKER-2-1361"></a><a name="MARKER-2-1362"></a>An
implementation may choose to impose fewer restrictions than specified. For
example, a class specified as sealed may be left open, and a class specified as
primary may be left free. However, any program that takes advantage of this
liberality will not be portable.</p>
-<p class="T1.Text1">Each class entry includes tables of operations defined on
the class. These tables are cross references to <a
href="Built-In_Functions">Chapter 12, "The Built-In Functions,"</a> and
represent redundant information. A function, generic function, or method is
listed under a class if one of its arguments is specialized on the class. In
addition, constructors are listed. Not all generic functions that specialize on
<code><object></code> are listed.<a name="MARKER-2-1363"></a></p>
+<p>The superclasses listed for a class <var>C</var> are those classes defined
by the Dylan language from which <var>C</var> most directly inherits. They are
not required to be the direct superclasses of <var>C</var>, because
implementations are free to insert implementation-defined classes in the class
hierarchy. However, any classes defined by Dylan that appear in the class
precedence list of <var>C</var> must appear in the same order in which they
would appear if the specified superclasses were the direct superclasses of
<var>C</var>, in the order given.</p>
+<p>All classes are specified as open or sealed. A class may be specifed as
abstract; if it is not, then it is concrete. A class may be specified as
primary; if it is not, than it is free. A class may be specified as
instantiable. If it is not, then it is uninstantiable. <a
href="Sealing">Chapter 9, "Sealing,"</a> contains a complete description of
these characteristics.</p>
+<p><a name="MARKER-2-1361"></a><a name="MARKER-2-1362"></a>An implementation
may choose to impose fewer restrictions than specified. For example, a class
specified as sealed may be left open, and a class specified as primary may be
left free. However, any program that takes advantage of this liberality will
not be portable.</p>
+<p>Each class entry includes tables of operations defined on the class. These
tables are cross references to <a href="Built-In_Functions">Chapter 12, "The
Built-In Functions,"</a> and represent redundant information. A function,
generic function, or method is listed under a class if one of its arguments is
specialized on the class. In addition, constructors are listed. Not all generic
functions that specialize on <code><object></code> are listed.<a
name="MARKER-2-1363"></a></p>
</div>
Modified: trunk/www/books/drm/Built-In_Functions_Overview.html
==============================================================================
--- trunk/www/books/drm/Built-In_Functions_Overview.html (original)
+++ trunk/www/books/drm/Built-In_Functions_Overview.html Mon Dec 19
00:04:11 2005
@@ -120,13 +120,13 @@
<a name="HEADING97-0"></a>
<a name="UID-Built-In_Functions-20433"></a>
<h1 class="section-title">Overview</h1>
-<p class="T1.Text1"><a name="MARKER-2-1528"></a>This chapter contains an entry
for each function defined by Dylan.</p>
-<p class="T1.Text1"><a name="MARKER-2-1529"></a>The functions described below
are annotated either as an "open generic function" or as a "function."</p>
-<p class="T1.Text1">A function specified as an "<a
name="MARKER-2-1530"></a>open generic function" can be extended through the
addition of programmer defined methods. The signature of the generic function
constrains which methods can be added through the congruency rules described on
<a href="Parameter_Lists#MARKER-9-837">page 93</a>. The signature does not
imply a set of <a name="MARKER-2-1531"></a>predefined methods. For example, the
signature of <code>+</code> is <code>(<object>, <object>)</code>,
but the predefined methods on <code>+</code> only cover subtypes of
<code><number></code>. Particular behavior of the function is given in
its description and in the description of its methods.</p>
-<p class="T1.Text1"><a name="MARKER-2-1532"></a>A function specified as a
"function" cannot portably be extended through the addition of methods.
Implementations are free to implement these functions as open generic
functions, but programs that take advantage of such <a
name="MARKER-2-1533"></a>liberality will not be portable. The signature of such
a function specifies the types of the arguments to which the function may be
applicable, but does not necessarily imply that the function is applicable to
all instances of the types. The exact behavior of the function is given in its
description.</p>
-<p class="T1.Text1">Implementations are allowed to define these generic
functions and functions with signatures that are less restrictive than those
given below. However, programs that take advantage of this liberality will not
be portable.</p>
-<p class="T1.Text1">When a method is specified, it describes the behavior of a
generic function when applied to arguments of particular types. It does not
imply that this behavior is implemented by a single method. A method described
as "<a name="MARKER-2-1534"></a>sealed" specifies a sealed domain covering the
generic function and specializers of the method.</p>
-<p class="T1.Text1">Where a sealed domain is specified, implementations are
free to seal the domain or leave the domain unsealed. Portable programs should
not rely on the domain being unsealed.<a name="MARKER-2-1535"></a></p>
+<p><a name="MARKER-2-1528"></a>This chapter contains an entry for each
function defined by Dylan.</p>
+<p><a name="MARKER-2-1529"></a>The functions described below are annotated
either as an "open generic function" or as a "function."</p>
+<p>A function specified as an "<a name="MARKER-2-1530"></a>open generic
function" can be extended through the addition of programmer defined methods.
The signature of the generic function constrains which methods can be added
through the congruency rules described on <a
href="Parameter_Lists#MARKER-9-837">page 93</a>. The signature does not imply a
set of <a name="MARKER-2-1531"></a>predefined methods. For example, the
signature of <code>+</code> is <code>(<object>, <object>)</code>,
but the predefined methods on <code>+</code> only cover subtypes of
<code><number></code>. Particular behavior of the function is given in
its description and in the description of its methods.</p>
+<p><a name="MARKER-2-1532"></a>A function specified as a "function" cannot
portably be extended through the addition of methods. Implementations are free
to implement these functions as open generic functions, but programs that take
advantage of such <a name="MARKER-2-1533"></a>liberality will not be portable.
The signature of such a function specifies the types of the arguments to which
the function may be applicable, but does not necessarily imply that the
function is applicable to all instances of the types. The exact behavior of the
function is given in its description.</p>
+<p>Implementations are allowed to define these generic functions and functions
with signatures that are less restrictive than those given below. However,
programs that take advantage of this liberality will not be portable.</p>
+<p>When a method is specified, it describes the behavior of a generic function
when applied to arguments of particular types. It does not imply that this
behavior is implemented by a single method. A method described as "<a
name="MARKER-2-1534"></a>sealed" specifies a sealed domain covering the generic
function and specializers of the method.</p>
+<p>Where a sealed domain is specified, implementations are free to seal the
domain or leave the domain unsealed. Portable programs should not rely on the
domain being unsealed.<a name="MARKER-2-1535"></a></p>
</div>
Modified:
trunk/www/books/drm/Built-In_Macros_and_Special_Definitions_Overview.html
==============================================================================
--- trunk/www/books/drm/Built-In_Macros_and_Special_Definitions_Overview.html
(original)
+++ trunk/www/books/drm/Built-In_Macros_and_Special_Definitions_Overview.html
Mon Dec 19 00:04:11 2005
@@ -116,7 +116,7 @@
<h1 class="section-title">Overview</h1>
<p class="T0.Text0">This chapter contains descriptions of the built-in
macros and special
definitions defined by Dylan.</p>
- <p class="T1.Text1">The syntax used in this chapter is described
+ <p>The syntax used in this chapter is described
in <a href="Manual_Notation#MARKER-9-173">"Manual Notation" on page
6</a>.</p>
</div>
Modified: trunk/www/books/drm/Classes.html
==============================================================================
--- trunk/www/books/drm/Classes.html (original)
+++ trunk/www/books/drm/Classes.html Mon Dec 19 00:04:11 2005
@@ -124,14 +124,14 @@
<a name="HEADING41-0"></a>
<a name="UID-Types_and_Classes-361"></a>
<h1 class="section-title"><a name="MARKER-2-561"></a>Classes</h1>
-<p class="T1.Text1"><a name="MARKER-2-562"></a>Classes are used to define the
inheritance, structure, and initialization of objects.</p>
-<p class="T1.Text1">Every object is a <dfn id="MARKER-2-563">direct
instance</dfn> of exactly one class, and a general instance of the <dfn
id="MARKER-2-564">general superclasses</dfn> of that class.</p>
-<p class="T1.Text1">A class determines which <dfn
id="MARKER-2-565">slots</dfn> its instances have. Slots are the local storage
available within instances. They are used to store the state of objects.</p>
-<p class="T1.Text1">Classes determine how their instances are initialized by
using the <dfn id="MARKER-2-566">initialization protocol</dfn>.</p>
+<p><a name="MARKER-2-562"></a>Classes are used to define the inheritance,
structure, and initialization of objects.</p>
+<p>Every object is a <dfn id="MARKER-2-563">direct instance</dfn> of exactly
one class, and a general instance of the <dfn id="MARKER-2-564">general
superclasses</dfn> of that class.</p>
+<p>A class determines which <dfn id="MARKER-2-565">slots</dfn> its instances
have. Slots are the local storage available within instances. They are used to
store the state of objects.</p>
+<p>Classes determine how their instances are initialized by using the <dfn
id="MARKER-2-566">initialization protocol</dfn>.</p>
<a name="HEADING41-5"></a>
<a name="UID-Types_and_Classes-5438"></a>
<h2 class="subsection-title"><a name="MARKER-2-567"></a>Features of
Classes</h2>
-<p class="T1.Text1">There are four features of classes. These features relate
to each other, but can be declared independently.</p>
+<p>There are four features of classes. These features relate to each other,
but can be declared independently.</p>
<ul>
<li>A class can be <dfn id="MARKER-2-568">abstract</dfn> or <dfn
id="MARKER-2-569">concrete</dfn>. If the class is concrete, it can have direct
instances. If it is abstract, it cannot have direct instances, but only
indirect instances.</li>
<li>A class can be <dfn id="MARKER-2-570">instantiable</dfn> or <dfn
id="MARKER-2-571">uninstantiable</dfn>. If the class is instantiable, it can be
used as the first argument to <code>make</code>. If it is uninstantiable, it
cannot be used as the first argument to <code>make</code>.</li>
@@ -141,15 +141,15 @@
<a name="HEADING41-11"></a>
<a name="UID-Types_and_Classes-2532"></a>
<h2 class="subsection-title"><a name="MARKER-2-577"></a>Creating Classes</h2>
-<p class="T1.Text1">New classes may be created by calling <code
id="MARKER-2-578">make</code> on <code><class></code>, or with the
definition <code id="MARKER-2-579">define class</code>. In most programs the
latter is more commonly used.</p>
-<p class="T1.Text1">When a class is created with <code>make</code>, it is
instantiated and returned just like any other object. The options available
when creating a class with <code>make</code> are described on <a
href="Type_Classes#MARKER-9-1372">page 191</a>.</p>
-<p class="T1.Text1"><a name="MARKER-2-580"></a>When a class is created with
<code>define class</code> it is used to initialize a new module binding.
<code>define class</code> allows the specification of superclasses, slots,
initialization behavior, and options related to sealing. The complete syntax of
<code>define class</code> is given on <a
href="Definition_Macros#MARKER-9-2013">page 378</a>.</p>
-<p class="T1.Text1">The following simple class definition creates a class
named by the module binding <code><new></code>. The class inherits from
<code><object></code> and does not specify any slots.</p>
+<p>New classes may be created by calling <code id="MARKER-2-578">make</code>
on <code><class></code>, or with the definition <code
id="MARKER-2-579">define class</code>. In most programs the latter is more
commonly used.</p>
+<p>When a class is created with <code>make</code>, it is instantiated and
returned just like any other object. The options available when creating a
class with <code>make</code> are described on <a
href="Type_Classes#MARKER-9-1372">page 191</a>.</p>
+<p><a name="MARKER-2-580"></a>When a class is created with <code>define
class</code> it is used to initialize a new module binding. <code>define
class</code> allows the specification of superclasses, slots, initialization
behavior, and options related to sealing. The complete syntax of <code>define
class</code> is given on <a href="Definition_Macros#MARKER-9-2013">page
378</a>.</p>
+<p>The following simple class definition creates a class named by the module
binding <code><new></code>. The class inherits from
<code><object></code> and does not specify any slots.</p>
<pre class="code">
define class <new> (<object>)
end class <new>;
</pre>
-<p class="T1.Text1">The following class definition illustrates the creation of
a class with multiple superclasses. Again, there are no slots defined by the
class.</p>
+<p>The following class definition illustrates the creation of a class with
multiple superclasses. Again, there are no slots defined by the class.</p>
<pre class="code">
define class <color-window> (<palette>, <window>)
end class <color-window>;<a name="MARKER-2-581"></a>
@@ -157,28 +157,28 @@
<a name="HEADING41-19"></a>
<a name="UID-Types_and_Classes-5460"></a>
<h2 class="subsection-title"><a name="MARKER-2-582"></a><a
name="MARKER-9-583"></a>Class Inheritance</h2>
-<p class="T1.Text1">When a class is created, its <dfn id="MARKER-2-584">direct
superclasses</dfn> are specified. The new class directly inherits from these
classes; it is a <dfn id="MARKER-2-585">direct subclass</dfn> of each of these
classes. There can be no duplicates in the direct superclasses of a class.</p>
-<p class="T1.Text1">The subclass relationship is transitive. If a class
<var>C</var> is a direct subclass of <var>C<em><sub>1</sub></em></var>,
<var>C<em><sub>1</sub></em></var> is a direct subclass of
<var>C<em><sub>2</sub></em></var>, and <var>C<em><sub>2</sub></em></var> is a
direct subclass of <var>C<em><sub>3</sub></em></var>, then <var>C</var> is an
<dfn id="MARKER-2-586">indirect subclass</dfn> of
<var>C<em><sub>2</sub></em></var> and <var>C<em><sub>3</sub></em></var>. A <dfn
id="MARKER-2-587">general subclass</dfn> is a direct or indirect subclass.</p>
-<p class="T1.Text1">Inheritance cannot be <a name="MARKER-2-588"></a>circular.
A class cannot be its own general subclass.</p>
-<p class="T1.Text1">A class is a subtype of each of its general
superclasses.</p>
-<p class="T1.Text1">Every class is a general subclass of
<code><object></code>.<a name="MARKER-2-589"></a></p>
+<p>When a class is created, its <dfn id="MARKER-2-584">direct
superclasses</dfn> are specified. The new class directly inherits from these
classes; it is a <dfn id="MARKER-2-585">direct subclass</dfn> of each of these
classes. There can be no duplicates in the direct superclasses of a class.</p>
+<p>The subclass relationship is transitive. If a class <var>C</var> is a
direct subclass of <var>C<em><sub>1</sub></em></var>,
<var>C<em><sub>1</sub></em></var> is a direct subclass of
<var>C<em><sub>2</sub></em></var>, and <var>C<em><sub>2</sub></em></var> is a
direct subclass of <var>C<em><sub>3</sub></em></var>, then <var>C</var> is an
<dfn id="MARKER-2-586">indirect subclass</dfn> of
<var>C<em><sub>2</sub></em></var> and <var>C<em><sub>3</sub></em></var>. A <dfn
id="MARKER-2-587">general subclass</dfn> is a direct or indirect subclass.</p>
+<p>Inheritance cannot be <a name="MARKER-2-588"></a>circular. A class cannot
be its own general subclass.</p>
+<p>A class is a subtype of each of its general superclasses.</p>
+<p>Every class is a general subclass of <code><object></code>.<a
name="MARKER-2-589"></a></p>
<a name="HEADING41-25"></a>
<a name="UID-Types_and_Classes-7969"></a>
<h2 class="subsection-title"><a name="MARKER-9-590"></a><a
name="MARKER-2-591"></a>Computing the Class Precedence List</h2>
-<p class="T1.Text1">The definition of a class specifies a <a
name="MARKER-2-592"></a>total ordering on that class and its direct
superclasses. This ordering is called the <dfn id="MARKER-2-593">local
precedence order</dfn>. In the local precedence order:</p>
+<p>The definition of a class specifies a <a name="MARKER-2-592"></a>total
ordering on that class and its direct superclasses. This ordering is called the
<dfn id="MARKER-2-593">local precedence order</dfn>. In the local precedence
order:</p>
<ul>
<li>The class precedes its direct superclasses.</li>
<li>Each direct superclass precedes all other direct superclasses that
follow it in the sequence of direct superclasses given in the class
definition.</li>
</ul>
-<p class="T1.Text1">The <dfn id="MARKER-2-594">class precedence list</dfn> for
a class <var>C</var> is a total ordering on <var>C</var> and its superclasses
that is consistent with the local precedence order of <var>C</var> and with the
class precedence lists of its superclasses. (Two lists are consistent if for
every <var>A</var> and <var>B</var> that are each members of both lists, either
<var>A</var> precedes <var>B</var> in both or <var>B</var> precedes
<var>A</var> in both.) The class precedence list is used in determining the
order of specificity of methods based on the types they are specialized on when
dispatching; for details, see <a href="Method_Dispatch#MARKER-9-844">"Method
Dispatch" on page 95</a>.</p>
-<p class="T1.Text1">Sometimes there are several such consistent total
orderings on <var>C</var> and its superclasses. Dylan uses a deterministic
algorithm to compute the class precedence list, which chooses one of the
consistent total orderings.</p>
-<p class="T1.Text1">Sometimes there is no possible total ordering on
<var>C</var> and its superclasses that is consistent with the local precedence
orders for <var>C</var> and with the class precedence lists of its
superclasses. In this case, the class precedence list cannot be computed, and
an error is signaled.</p>
-<p class="T1.Text1">Note that because the class precedence list for a class is
consistent with the class precedence lists of its superclasses, inheritance in
Dylan is <dfn>monotonic</dfn>. That is, if a generic function call using a
direct instance of <var>C</var> dispatches to a method specialized in that
parameter position on an indirect superclass of <var>C</var>, then there is a
direct superclass of <var>C</var> that has the same behavior.</p>
-<p class="T1.Text1">To compute the class precedence list for class
<var>C</var>, merge the local precedence order of the class with the class
precedence lists of the direct superclasses of the class. Computing the class
precedence list for <var>C</var> requires computing the class precedence lists
for its superclasses. This does not lead to infinite recursion because circular
class inheritance is prohibited.</p>
-<p class="T1.Text1"><a name="MARKER-2-595"></a>Note that because the class
precedence lists of the direct superclasses are consistent with their local
precedence orders and with the class precedence lists of their direct
superclasses, and so on, the class precedence list for <var>C</var> is
consistent with the local precedence orders and class precedence lists of all
its superclasses and not just the direct superclasses.</p>
-<p class="T1.Text1">The merge of several sequences is a sequence that contains
each of the elements of the several input sequences. An element that appears in
more than one of the input sequences appears only once in the output sequence.
If two elements appear in the same input sequence, their order in the output
sequence is the same as their order in that input sequence.</p>
-<p class="T1.Text1">When there are several possible merges of the inputs, at
each position in the output where there is a choice, pick the class that has a
direct subclass closest to the end of the output sequence. (This is unambiguous
because two candidates for a position cannot both be direct superclasses of the
same class, since they would then be ordered by that class's local precedence
order. This is easily computable because a class always follows its direct
subclasses in the merge, therefore the most recently added direct subclass can
be found by searching from the end to the beginning of the output sequence and
the merge can be computed in one pass.)</p>
-<p class="T1.Text1">This algorithm can be implemented with the following Dylan
program:</p>
+<p>The <dfn id="MARKER-2-594">class precedence list</dfn> for a class
<var>C</var> is a total ordering on <var>C</var> and its superclasses that is
consistent with the local precedence order of <var>C</var> and with the class
precedence lists of its superclasses. (Two lists are consistent if for every
<var>A</var> and <var>B</var> that are each members of both lists, either
<var>A</var> precedes <var>B</var> in both or <var>B</var> precedes
<var>A</var> in both.) The class precedence list is used in determining the
order of specificity of methods based on the types they are specialized on when
dispatching; for details, see <a href="Method_Dispatch#MARKER-9-844">"Method
Dispatch" on page 95</a>.</p>
+<p>Sometimes there are several such consistent total orderings on <var>C</var>
and its superclasses. Dylan uses a deterministic algorithm to compute the class
precedence list, which chooses one of the consistent total orderings.</p>
+<p>Sometimes there is no possible total ordering on <var>C</var> and its
superclasses that is consistent with the local precedence orders for
<var>C</var> and with the class precedence lists of its superclasses. In this
case, the class precedence list cannot be computed, and an error is
signaled.</p>
+<p>Note that because the class precedence list for a class is consistent with
the class precedence lists of its superclasses, inheritance in Dylan is
<dfn>monotonic</dfn>. That is, if a generic function call using a direct
instance of <var>C</var> dispatches to a method specialized in that parameter
position on an indirect superclass of <var>C</var>, then there is a direct
superclass of <var>C</var> that has the same behavior.</p>
+<p>To compute the class precedence list for class <var>C</var>, merge the
local precedence order of the class with the class precedence lists of the
direct superclasses of the class. Computing the class precedence list for
<var>C</var> requires computing the class precedence lists for its
superclasses. This does not lead to infinite recursion because circular class
inheritance is prohibited.</p>
+<p><a name="MARKER-2-595"></a>Note that because the class precedence lists of
the direct superclasses are consistent with their local precedence orders and
with the class precedence lists of their direct superclasses, and so on, the
class precedence list for <var>C</var> is consistent with the local precedence
orders and class precedence lists of all its superclasses and not just the
direct superclasses.</p>
+<p>The merge of several sequences is a sequence that contains each of the
elements of the several input sequences. An element that appears in more than
one of the input sequences appears only once in the output sequence. If two
elements appear in the same input sequence, their order in the output sequence
is the same as their order in that input sequence.</p>
+<p>When there are several possible merges of the inputs, at each position in
the output where there is a choice, pick the class that has a direct subclass
closest to the end of the output sequence. (This is unambiguous because two
candidates for a position cannot both be direct superclasses of the same class,
since they would then be ordered by that class's local precedence order. This
is easily computable because a class always follows its direct subclasses in
the merge, therefore the most recently added direct subclass can be found by
searching from the end to the beginning of the output sequence and the merge
can be computed in one pass.)</p>
+<p>This algorithm can be implemented with the following Dylan program:</p>
<pre class="code">
define constant compute-class-linearization =
method (c :: <class>) => (cpl :: <list>)
Modified: trunk/www/books/drm/Coercing_and_Copying_Objects.html
==============================================================================
--- trunk/www/books/drm/Coercing_and_Copying_Objects.html (original)
+++ trunk/www/books/drm/Coercing_and_Copying_Objects.html Mon Dec 19
00:04:11 2005
@@ -297,32 +297,32 @@
of <var>type</var> that has the same contents as <var>object</var>.
If <var>object</var>
is already an instance of <var>type</var>, it is returned unchanged.
In general, the value
returned may or may not be freshly allocated.</p>
- <p class="T1.Text1">Predefined methods allow coercion between
integers and characters,
- between strings and symbols, and between collection types. No methods
are predefined for
- other classes. Programs may define additional methods.</p>
+ <p>Predefined methods allow coercion between integers and characters,
between strings and
+ symbols, and between collection types. No methods are predefined for
other
+ classes. Programs may define additional methods.</p>
<a name="HEADING101-24"></a>
<h5 class="method-signature"><span class="signature"><code>as
<var>collection-type collection</var> </code>
⇒<code> <var>instance-of-collection-type</var></code>
</span><span class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">When converting between collection types, the
return value will have
- the same number of elements as <var>collection</var>. If the
<var>collection</var> is an
- instance of <code><sequence></code> and the
<var>collection-type</var> is a subtype
+ <p>When converting between collection types, the return value will
have the same number of
+ elements as <var>collection</var>. If the <var>collection</var> is an
instance
+ of <code><sequence></code> and the <var>collection-type</var>
is a subtype
of <code><sequence></code>, the elements will be in the same
order. The individual
elements may also undergo some conversion. The specific collection
types for
which <code>as</code> is defined is implementation defined.</p>
<a name="HEADING101-26"></a>
<h5 class="method-signature"><span class="signature"><code>as
<em>(singleton (<integer>))</em> <var>character</var> </code>
⇒<code> <var>integer</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">This method on <code>as</code> returns a numeric
equivalent
+ <p>This method on <code>as</code> returns a numeric equivalent
for <var>character</var>. The integer returned is implementation
dependent.</p>
<a name="HEADING101-28"></a>
<h5 class="method-signature"><span class="signature"><code>as
<em>(singleton (<character>))</em> <var>integer</var> </code>
⇒<code> <var>character</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">This method on <code>as</code> returns the
character equivalent
+ <p>This method on <code>as</code> returns the character equivalent
to <var>integer</var>. The meaning of <var>integer</var> is
implementation dependent.</p>
<a name="HEADING101-30"></a>
<h5 class="method-signature"><span class="signature"><code>as
<em>(singleton (<symbol>))</em> <var>string</var> </code>
⇒<code> <var>symbol</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">This method on <code>as</code> returns the symbol
that has the
+ <p>This method on <code>as</code> returns the symbol that has the
name <var>string</var>. If the symbol does not yet exist, it is
created. This method
on <code>as</code> will always return the same symbol for strings of
the same characters,
without regard to alphabetic case.</p>
@@ -336,8 +336,8 @@
<a name="HEADING101-33"></a>
<h5 class="method-signature"><span class="signature"><code>as
<em>(singleton (<string>))</em> <var>symbol</var> </code>
⇒<code> <var>string</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">This method on <code>as</code> returns the name
of the symbol, which
- will be a string.</p>
+ <p>This method on <code>as</code> returns the name of the symbol,
which will be a
+ string.</p>
<pre class="code">
as (<string>, #"Foo")
<code> ⇒</code> "Foo"</pre>
@@ -379,18 +379,17 @@
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche">
<p>Coerces an object to uppercase and returns the resulting new
object.</p>
- <p class="T1.Text1"><var>object1</var> is not modified by this
operation.</p>
+ <p><var>object1</var> is not modified by this operation.</p>
<a name="HEADING101-44"></a>
<h5 class="method-signature"><span
class="signature"><code>as-uppercase <var>character</var> </code>
⇒<code> <var>uppercase-character</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">This method returns the uppercase equivalent
+ <p>This method returns the uppercase equivalent
for <var>character</var>. If <var>character</var> already is
uppercase or does not exist
in two cases, it is returned unchanged.</p>
<a name="HEADING101-46"></a>
<h5 class="method-signature"><span
class="signature"><code>as-uppercase <var>string</var> </code>
⇒<code> <var>new-string</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">This method is equivalent
- to <code>map(as-uppercase, <var>string</var>)</code>.</p>
+ <p>This method is equivalent to <code>map(as-uppercase,
<var>string</var>)</code>.</p>
</dd>
</dl>
<a name="HEADING101-48"></a>
@@ -427,12 +426,12 @@
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche">
<p>Coerces an object to uppercase in place and returns the modified
object.</p>
- <p class="T1.Text1"><var>object</var> may be modified by this
operation, and the result
- will be <code>==</code> to the <var>object</var>.</p>
+ <p><var>object</var> may be modified by this operation, and the
result will
+ be <code>==</code> to the <var>object</var>.</p>
<a name="HEADING101-55"></a>
<h5 class="method-signature"><span
class="signature"><code>as-uppercase! <var>string</var> </code>
⇒<code> <var>string</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">This method is equivalent to
<code>map-into(<var>string</var>,
+ <p>This method is equivalent to <code>map-into(<var>string</var>,
as-uppercase, <var>string</var>)</code>.</p>
</dd>
</dl>
@@ -469,18 +468,17 @@
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche">
<p>Coerces an object to lowercase and returns the resulting new
object.</p>
- <p class="T1.Text1"><var>object1</var> will not be modified by this
operation.</p>
+ <p><var>object1</var> will not be modified by this operation.</p>
<a name="HEADING101-64"></a>
<h5 class="method-signature"><span
class="signature"><code>as-lowercase <var>character</var> </code>
⇒<code> <var>lowercase-character</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">The <code><character></code> method on
<code>as-lowercase</code>
- returns the lowercase equivalent for <var>character</var>. If
<var>character</var> already
- is lowercase or does not exist in two cases, it is returned
unchanged.</p>
+ <p>The <code><character></code> method on
<code>as-lowercase</code> returns the
+ lowercase equivalent for <var>character</var>. If
<var>character</var> already is
+ lowercase or does not exist in two cases, it is returned
unchanged.</p>
<a name="HEADING101-66"></a>
<h5 class="method-signature"><span
class="signature"><code>as-lowercase <var>string</var> </code>
⇒<code> <var>new-string</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">This method is equivalent
- to <code>map(as-lowercase, <var>string</var>)</code>.</p>
+ <p>This method is equivalent to <code>map(as-lowercase,
<var>string</var>)</code>.</p>
</dd>
</dl>
<a name="HEADING101-68"></a>
@@ -517,12 +515,12 @@
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche">
<p>Coerces an object to lowercase in place and returns the modified
object.</p>
- <p class="T1.Text1"><var>object</var> may be modified by this
operation, and the result
- will be <code>==</code> to the <var>object</var>.</p>
+ <p><var>object</var> may be modified by this operation, and the
result will
+ be <code>==</code> to the <var>object</var>.</p>
<a name="HEADING101-75"></a>
<h5 class="method-signature"><span
class="signature"><code>as-lowercase! <var>string</var> </code>
⇒<code> <var>string</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">This method is equivalent to
<code>map-into(<var>string</var>, as-lowercase, <var>string</var>)</code>.<a
name="MARKER-2-1690"></a></p>
+ <p>This method is equivalent to <code>map-into(<var>string</var>,
as-lowercase, <var>string</var>)</code>.<a name="MARKER-2-1690"></a></p>
</dd>
</dl>
<a name="HEADING101-77"></a>
@@ -562,13 +560,12 @@
<dd class="Cliche">
<p>Returns a new object that has the same contents as
<var>object1</var>. The contents are
not copied but are the same objects contained in
<var>object1</var>.</p>
- <p class="T1.Text1">There is a predefined method for instances
- of <code><collection></code>. For other classes, the programmer
must provide a
- method.</p>
+ <p>There is a predefined method for instances of
<code><collection></code>. For
+ other classes, the programmer must provide a method.</p>
<a name="HEADING101-85"></a>
<h5 class="method-signature"><span
class="signature"><code>shallow-copy <var>collection</var> </code>
⇒<code> <var>new-collection</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">The method for <code><collection></code>
creates a new object by
+ <p>The method for <code><collection></code> creates a new
object by
calling <code>make</code> on the <code>type-for-copy</code> of
<var>collection</var> and
filling it with the same elements as <var>collection</var>.</p>
</dd>
@@ -607,30 +604,30 @@
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche">
<p>Returns an appropriate type for creating mutable copies of
<var>object</var>.</p>
- <p class="T1.Text1">The <code>type-for-copy</code> value of a
collection must be an
- instantiable subtype of <code><mutable-collection></code>. For
collections that are
- themselves mutable, the collection's actual class is generally the
most appropriate
- (assuming it is instantiable). The <code>type-for-copy</code> value
for a sequence should
- be a subtype of <code><sequence></code>, and the
<code>type-for-copy</code> value of
- an explicit-key-collection should be a subtype
+ <p>The <code>type-for-copy</code> value of a collection must be an
instantiable subtype
+ of <code><mutable-collection></code>. For collections that are
themselves mutable,
+ the collection's actual class is generally the most appropriate
(assuming it is
+ instantiable). The <code>type-for-copy</code> value for a sequence
should be a subtype
+ of <code><sequence></code>, and the <code>type-for-copy</code>
value of an
+ explicit-key-collection should be a subtype
of <code><explicit-key-collection></code>.</p>
<a name="HEADING101-94"></a>
<h5 class="method-signature"><span
class="signature"><code>type-for-copy <var>object</var> </code>
⇒<code> <var>type</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">The method on <code><object></code> returns
the result of
+ <p>The method on <code><object></code> returns the result of
calling <code>object-class</code> on the <var>object</var>.</p>
<a name="HEADING101-96"></a>
<h5 class="method-signature"><span
class="signature"><code>type-for-copy <var>mutable-collection</var> </code>
⇒<code> <var>type</var></code> </span><span
class="attributes-summary">[G.F. Method]</span></h5>
- <p class="T1.Text1">The method on
<code><mutable-collection></code> returns the
- result of calling <code>object-class</code> on the
<var>mutable-collection</var>.</p>
+ <p>The method on <code><mutable-collection></code> returns the
result of
+ calling <code>object-class</code> on the
<var>mutable-collection</var>.</p>
<a name="HEADING101-98"></a>
<h5 class="method-signature"><span
class="signature"><code>type-for-copy <var>limited-collection</var> </code>
⇒<code> <var>type</var></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">For a type <var>L<em><sub>1</sub></em></var>
created
- by <code>limited(<var>C</var>, of: <var>T</var>, size:
<var>S</var>)</code>
- where <var>C</var> is not <code><range></code>,
<code>type-for-copy</code> of an
- object made by instantiating <var>L<em><sub>1</sub></em></var>
returns a
+ <p>For a type <var>L<em><sub>1</sub></em></var> created by
<code>limited(<var>C</var>,
+ of: <var>T</var>, size: <var>S</var>)</code> where <var>C</var> is
+ not <code><range></code>, <code>type-for-copy</code> of an
object made by
+ instantiating <var>L<em><sub>1</sub></em></var> returns a
type <var>L<em><sub>2</sub></em></var> that satisfies each of the
following:</p>
<ul>
<li><var>L<em><sub>2</sub></em></var> is either a class or a
limited collection type.</li>
@@ -641,11 +638,11 @@
<a name="HEADING101-104"></a>
<h5 class="method-signature"><span
class="signature"><code>type-for-copy <var>range</var> </code>
⇒<code> <list></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">The method on <code><range></code> returns
<code><list></code>.</p>
+ <p>The method on <code><range></code> returns
<code><list></code>.</p>
<a name="HEADING101-106"></a>
<h5 class="method-signature"><span
class="signature"><code>type-for-copy <var>limited-range</var> </code>
⇒<code> <list></code> </span><span
class="attributes-summary">[Sealed G.F. Method]</span></h5>
- <p class="T1.Text1">The method on instances
+ <p>The method on instances
of <code>limited(singleton(<range>)</code>…<code>)</code>
returns <code><list></code>, the same as for any instance
of <code><range></code>.<a name="MARKER-2-1695"></a></p>
Modified: trunk/www/books/drm/Collection_Alignment.html
==============================================================================
--- trunk/www/books/drm/Collection_Alignment.html (original)
+++ trunk/www/books/drm/Collection_Alignment.html Mon Dec 19 00:04:11 2005
@@ -119,11 +119,11 @@
<a name="HEADING65-0"></a>
<a name="UID-Collections-2808"></a>
<h1 class="section-title"><a name="MARKER-9-1021"></a>Collection Alignment</h1>
-<p class="T1.Text1"><a name="MARKER-2-1022"></a>Some operations on collections
are defined to allow the use of more than a single collection. For example,
some looping functions accept any number of collections and operate on these
collections in parallel. Each pass through the loop uses one element from each
collection. The presence of collections that are unstable under iteration can
create problems for multi-collection operations unless special care is taken.
If iteration is effectively performed in random order, then naively performing
parallel iterations over two different collections would randomly combine
values from the two collections. This would presumably have no meaning.</p>
-<p class="T1.Text1">To prevent such random combinations, operations on more
than one collection must in general align the collections. <dfn>Collection
alignment</dfn> consists of effectively computing the intersection of the
collections' key sequences and then using the random-access operations
(<code>element</code> and <code>element-setter</code>) to operate on the
collections themselves.</p>
-<p class="T1.Text1">If implemented naively, this definition of alignment has
the potential for extreme inefficiency because of its dependence on
<code>element</code> and the potential loops implied by the calls to
<code>key-sequence</code>. However, an important special case of this problem
is that of iterating over multiple sequences. In this case, the intersection of
key sequences will always be the non-negative integers up to the length of the
shortest sequence. Further, unlike collections in general, sequences are
required to exhibit stability so the explicit computation of key sequences is
not actually required. It is correct simply to iterate until one or more of the
sequences is exhausted.</p>
-<p class="T1.Text1">Iteration operations that store results in a target
collection must generally include the target collection during alignment. This
alignment requirement is relaxed if the target collection is a <code
id="MARKER-2-1023"><stretchy-collection></code>. In this case, the target
collection is not considered during alignment. Rather, only the source
collections are aligned. New keys may be added to the target collection during
the course of the iteration, and keys may be given new values. Other keys are
left undisturbed.</p>
-<p class="T1.Text1"><a name="MARKER-2-1024"></a>It is only possible to align
collections that have identical key tests.<a name="MARKER-2-1025"></a></p>
+<p><a name="MARKER-2-1022"></a>Some operations on collections are defined to
allow the use of more than a single collection. For example, some looping
functions accept any number of collections and operate on these collections in
parallel. Each pass through the loop uses one element from each collection. The
presence of collections that are unstable under iteration can create problems
for multi-collection operations unless special care is taken. If iteration is
effectively performed in random order, then naively performing parallel
iterations over two different collections would randomly combine values from
the two collections. This would presumably have no meaning.</p>
+<p>To prevent such random combinations, operations on more than one collection
must in general align the collections. <dfn>Collection alignment</dfn> consists
of effectively computing the intersection of the collections' key sequences and
then using the random-access operations (<code>element</code> and
<code>element-setter</code>) to operate on the collections themselves.</p>
+<p>If implemented naively, this definition of alignment has the potential for
extreme inefficiency because of its dependence on <code>element</code> and the
potential loops implied by the calls to <code>key-sequence</code>. However, an
important special case of this problem is that of iterating over multiple
sequences. In this case, the intersection of key sequences will always be the
non-negative integers up to the length of the shortest sequence. Further,
unlike collections in general, sequences are required to exhibit stability so
the explicit computation of key sequences is not actually required. It is
correct simply to iterate until one or more of the sequences is exhausted.</p>
+<p>Iteration operations that store results in a target collection must
generally include the target collection during alignment. This alignment
requirement is relaxed if the target collection is a <code
id="MARKER-2-1023"><stretchy-collection></code>. In this case, the target
collection is not considered during alignment. Rather, only the source
collections are aligned. New keys may be added to the target collection during
the course of the iteration, and keys may be given new values. Other keys are
left undisturbed.</p>
+<p><a name="MARKER-2-1024"></a>It is only possible to align collections that
have identical key tests.<a name="MARKER-2-1025"></a></p>
</div>
Modified: trunk/www/books/drm/Collection_Alteration_and_Allocation.html
==============================================================================
--- trunk/www/books/drm/Collection_Alteration_and_Allocation.html
(original)
+++ trunk/www/books/drm/Collection_Alteration_and_Allocation.html Mon Dec
19 00:04:11 2005
@@ -119,17 +119,17 @@
<a name="HEADING64-0"></a>
<a name="UID-Collections-3519"></a>
<h1 class="section-title"><a name="MARKER-9-1013"></a>Collection Alteration
and Allocation</h1>
-<p class="T1.Text1"><a name="MARKER-2-1014"></a>The contents of a collection
are the key/value pairs stored in the collection. The contents are said to be
<dfn>altered</dfn> when:</p>
+<p><a name="MARKER-2-1014"></a>The contents of a collection are the key/value
pairs stored in the collection. The contents are said to be <dfn>altered</dfn>
when:</p>
<ul>
<li><a name="MARKER-2-1015"></a>Keys are added or removed (according to the
collection's key test).</li>
<li>The value of a key (according to the key test) changes (as tested by
<code>==</code>).</li>
<li>The ordering of the key/value pairs changes. This type of alteration is
only possible for explicit key collections that are stable under iteration.</li>
</ul>
-<p class="T1.Text1">A function <dfn id="MARKER-2-1016">destructively
modifies</dfn> its argument collection if calling the function could alter the
contents of the argument collection. Unless explicitly documented to do so,
functions do not destructively modify their arguments.</p>
-<p class="T1.Text1">The <code>!</code> convention, described on <a
href="Naming_Conventions#MARKER-9-342">page 24</a>, is used to indicate some
destructive operations.</p>
-<p class="T1.Text1"><a name="MARKER-2-1017"></a>Unless explicity noted,
destructive operations are not required to leave their arguments in a
well-defined state. More particularly, a destructive operation does not in
general turn the argument into the result. It may reuse components of the
argument or alter the argument in some unpredictable way in order to produce
the result. As a general rule, the return value of the function should be
used.</p>
-<p class="T1.Text1">A collection <var>C </var>is <dfn
id="MARKER-2-1018">fresh</dfn> if modification of any pre-existing collection's
contents can never modify the contents of <var>C</var> and if modifications to
<var>C</var> can never modify the contents of any pre-existing collection. <a
name="MARKER-2-1019"></a>Immutable collections cannot be modified, so a fresh
immutable collection can share structure with other immutable collections.</p>
-<p class="T1.Text1">For example, given that <code><pair></code> is
mutable and the result of a call to <code>list</code> is a fresh instance of
<code><pair></code>, we can guarantee that the following expression is
always false:</p>
+<p>A function <dfn id="MARKER-2-1016">destructively modifies</dfn> its
argument collection if calling the function could alter the contents of the
argument collection. Unless explicitly documented to do so, functions do not
destructively modify their arguments.</p>
+<p>The <code>!</code> convention, described on <a
href="Naming_Conventions#MARKER-9-342">page 24</a>, is used to indicate some
destructive operations.</p>
+<p><a name="MARKER-2-1017"></a>Unless explicity noted, destructive operations
are not required to leave their arguments in a well-defined state. More
particularly, a destructive operation does not in general turn the argument
into the result. It may reuse components of the argument or alter the argument
in some unpredictable way in order to produce the result. As a general rule,
the return value of the function should be used.</p>
+<p>A collection <var>C </var>is <dfn id="MARKER-2-1018">fresh</dfn> if
modification of any pre-existing collection's contents can never modify the
contents of <var>C</var> and if modifications to <var>C</var> can never modify
the contents of any pre-existing collection. <a
name="MARKER-2-1019"></a>Immutable collections cannot be modified, so a fresh
immutable collection can share structure with other immutable collections.</p>
+<p>For example, given that <code><pair></code> is mutable and the result
of a call to <code>list</code> is a fresh instance of
<code><pair></code>, we can guarantee that the following expression is
always false:</p>
<pre class="code">
list(1) == list(1)<a name="MARKER-2-1020"></a>
</pre>
Modified: trunk/www/books/drm/Collection_Classes.html
==============================================================================
--- trunk/www/books/drm/Collection_Classes.html (original)
+++ trunk/www/books/drm/Collection_Classes.html Mon Dec 19 00:04:11 2005
@@ -190,9 +190,9 @@
<a name="HEADING93-0"></a>
<a name="UID-Built-In_Classes-9369"></a>
<h1 class="section-title"><a name="MARKER-9-1398"></a><a
name="MARKER-2-1399"></a>Collections</h1>
- <p class="T1.Text1">This section describes the built-in collections,
Dylan's aggregate data structures.</p>
- <p class="T1.Text1">Collections are used to hold groups of objects.
Collections support iteration as well as random access through collection keys.
An overview of collections is given in <a href="Collections">Chapter 8,
"Collections."</a></p>
- <p class="T1.Text1"><a href="#MARKER-9-1400">Figure 11-4</a> shows the
built-in collection classes and some of their characteristics.</p>
+ <p>This section describes the built-in collections, Dylan's aggregate
data structures.</p>
+ <p>Collections are used to hold groups of objects. Collections support
iteration as well as random access through collection keys. An overview of
collections is given in <a href="Collections">Chapter 8, "Collections."</a></p>
+ <p><a href="#MARKER-9-1400">Figure 11-4</a> shows the built-in
collection classes and some of their characteristics.</p>
<p class="figure"><strong>Figure</strong> <strong>11-4</strong> <a
name="MARKER-9-1400"></a>The Collection Classes</p>
<div class="figure wide" style="min-width: 715px">
@@ -262,16 +262,17 @@
<a name="HEADING93-6"></a>
<h4 class="item-title"><span class="signature"><code
id="MARKER-2-1401"><collection></code> </span><span
class="attributes-summary">[Open Abstract Class]</span></h4>
<hr class="item-title" />
- <p class="T1.Text1">The class of collections, aggregate data
structures.</p>
+ <p>The class of collections, aggregate data structures.</p>
<dl class="Cliche">
<dt class="Cliche"><span>Superclasses:</span></dt>
<dd class="Cliche"><p><code><object></code></p></dd>
<dt class="Cliche"><span>Init-keywords:</span></dt>
<dd class="Cliche"><p>None.</p></dd>
<dt class="Cliche"><span>Description:</span></dt>
- <dd class="Cliche"><p>The class of collections.</p>
- <p class="T1.Text1"><code><collection></code> is the root class
of the collection class hierarchy. It provides a set of basic operations on all
collections.</p>
- <p class="T1.Text1">The element type of
<code><collection></code> is <code>indefinite ⇐
<object></code>.</p></dd>
+ <dd class="Cliche">
+ <p>The class of collections.</p>
+ <p><code><collection></code> is the root class of the
collection class hierarchy. It provides a set of basic operations on all
collections.</p>
+ <p>The element type of <code><collection></code> is
<code>indefinite ⇐ <object></code>.</p></dd>
<dt class="Cliche"><span>Operations:</span></dt>
<dd class="Cliche"><p>The class <code><collection></code>
provides the following operations:</p>
<table class="numbered"><caption><strong>Table 11-16</strong>
Functions on <collection></caption>
@@ -361,7 +362,7 @@
<a name="HEADING93-375"></a>
<h4 class="item-title"><span class="signature"><code
id="MARKER-2-1402"><explicit-key-collection></code> </span><span
class="attributes-summary">[Open Abstract Class]</span></h4>
<hr class="item-title" />
- <p class="T1.Text1">The class of all collections that are not
sequences.</p>
+ <p>The class of all collections that are not sequences.</p>
<dl class="Cliche">
<dt class="Cliche"><span>Superclasses:</span></dt>
<dd class="Cliche"><p><code><collection></code></p></dd>
@@ -369,8 +370,8 @@
<dd class="Cliche"><p>None.</p></dd>
<dt class="Cliche"><span>Description:</span></dt>
<dd class="Cliche"><p>The class of all collections that are not
sequences.</p>
- <p class="T1.Text1">This class is disjoint from
<code><sequence></code> because <code>key-test</code> is sealed over the
domain <code><sequence></code>.</p>
- <p class="T1.Text1">The element type of
<code><explicit-key-collection></code> is <code>indefinite ⇐
<object></code>.</p></dd>
+ <p>This class is disjoint from <code><sequence></code> because
<code>key-test</code> is sealed over the domain
<code><sequence></code>.</p>
+ <p>The element type of <code><explicit-key-collection></code>
is <code>indefinite ⇐ <object></code>.</p></dd>
<dt class="Cliche"><span>Operations:</span></dt>
<dd class="Cliche"><p>The class
<code><explicit-key-collection></code> provides the following
operation:</p>
<table class="numbered"><caption><strong>Table 11-20</strong>
Methods on singleton(<explicit-key-collection>)</caption>
@@ -389,18 +390,19 @@
<a name="HEADING93-418"></a>
<h4 class="item-title"><span class="signature"><code
id="MARKER-2-1403"><sequence></code> </span><span
class="attributes-summary">[Open Abstract Class]</span></h4>
<hr class="item-title" />
- <p class="T1.Text1">The class of collections whose keys are consecutive
integers starting from zero.</p>
+ <p>The class of collections whose keys are consecutive integers starting
from zero.</p>
<dl class="Cliche">
<dt class="Cliche"><span>Superclasses:</span></dt>
<dd class="Cliche"><p><code><collection></code></p></dd>
<dt class="Cliche"><span>Init-keywords:</span></dt>
<dd class="Cliche"><p>None.</p></dd>
<dt class="Cliche"><span>Description:</span></dt>
- <dd class="Cliche"><p>The class of collections whose keys are
consecutive integers starting from zero.</p>
- <p class="T1.Text1"><a name="MARKER-2-1404"></a>Sequences must be
stable under iteration, and the iteration order must match the order of keys.
Thus, the key associated with a sequence's iteration state can be determined by
keeping a counter in parallel with the iteration state.</p>
- <p class="T1.Text1"><code><a name="MARKER-2-1405"></a><a
name="MARKER-2-1406"></a><a name="MARKER-2-1407"></a><a
name="MARKER-2-1408"></a><a name="MARKER-2-1409"></a><a
name="MARKER-2-1410"></a><a name="MARKER-2-1411"></a><a
name="MARKER-2-1412"></a><a name="MARKER-2-1413"></a><a
name="MARKER-2-1414"></a><a name="MARKER-2-1415"></a><a
name="MARKER-2-1416"></a></code>The default methods for <code>add</code>,
<code>add-new</code>, <code>remove</code>, <code>choose</code>,
<code>choose-by</code>, <code>intersection</code>, <code>union</code>,
<code>remove-duplicates</code>, <code>copy-sequence</code>,
<code>concatenate</code>, <code>reverse</code>, and <code>sort</code> all
return new sequences that are instances of the <code
id="MARKER-2-1417">type-for-copy</code> of their primary sequence argument.
However, more specialized methods are permitted to choose a more appropriate
result cla
ss; for example, <code>copy-sequence</code> of a range returns another range,
even though
the <code>type-for-copy</code> value of a range is the
<code><list></code> class.</p>
- <p class="T1.Text1"><code><sequence></code> is disjoint from
<code><explicit-key-collection></code> because of the sealed domain over
the function <code>key-test</code> for <code><sequence></code>.</p>
- <p class="T1.Text1">The element type of <code><sequence></code>
is <code>indefinite ⇐ <object></code>.</p></dd>
+ <dd class="Cliche">
+ <p>The class of collections whose keys are consecutive integers
starting from zero.</p>
+ <p><a name="MARKER-2-1404"></a>Sequences must be stable under
iteration, and the iteration order must match the order of keys. Thus, the key
associated with a sequence's iteration state can be determined by keeping a
counter in parallel with the iteration state.</p>
+ <p><code><a name="MARKER-2-1405"></a><a name="MARKER-2-1406"></a><a
name="MARKER-2-1407"></a><a name="MARKER-2-1408"></a><a
name="MARKER-2-1409"></a><a name="MARKER-2-1410"></a><a
name="MARKER-2-1411"></a><a name="MARKER-2-1412"></a><a
name="MARKER-2-1413"></a><a name="MARKER-2-1414"></a><a
name="MARKER-2-1415"></a><a name="MARKER-2-1416"></a></code>The default methods
for <code>add</code>, <code>add-new</code>, <code>remove</code>,
<code>choose</code>, <code>choose-by</code>, <code>intersection</code>,
<code>union</code>, <code>remove-duplicates</code>, <code>copy-sequence</code>,
<code>concatenate</code>, <code>reverse</code>, and <code>sort</code> all
return new sequences that are instances of the <code
id="MARKER-2-1417">type-for-copy</code> of their primary sequence argument.
However, more specialized methods are permitted to choose a more appropriate
result class; for example,
<code>copy-sequence</code> of a range returns another range, even though the
<code>type-fo
r-copy</code> value of a range is the <code><list></code> class.</p>
+ <p><code><sequence></code> is disjoint from
<code><explicit-key-collection></code> because of the sealed domain over
the function <code>key-test</code> for <code><sequence></code>.</p>
+ <p>The element type of <code><sequence></code> is
<code>indefinite ⇐ <object></code>.</p></dd>
<dt class="Cliche"><span>Operations:</span></dt>
<dd class="Cliche"><p>The class <code><sequence></code> provides
the following operations:</p>
<table class="numbered"><caption><strong>Table 11-21</strong>
Functions on <sequence></caption>
@@ -515,16 +517,17 @@
<a name="HEADING93-838"></a>
<h4 class="item-title"><span class="signature"><code
id="MARKER-2-1418"><mutable-collection></code> </span><span
class="attributes-summary">[Open Abstract Class]</span></h4>
<hr class="item-title" />
- <p class="T1.Text1">The class of collections that may be modified.</p>
+ <p>The class of collections that may be modified.</p>
<dl class="Cliche">
<dt class="Cliche"><span>Superclasses:</span></dt>
<dd class="Cliche"><p><code><collection></code></p></dd>
<dt class="Cliche"><span>Init-keywords:</span></dt>
<dd class="Cliche"><p>None.</p></dd>
<dt class="Cliche"><span>Description:</span></dt>
- <dd class="Cliche"><p>The class of collections that may be modified.</p>
- <p class="T1.Text1">Every mutable collection is required to allow
modification by implementing <code id="MARKER-2-1419">element-setter</code>.</p>
- <p class="T1.Text1">The element type of
<code><mutable-collection></code> is <code>indefinite ⇐
<object></code>.</p></dd>
+ <dd class="Cliche">
+ <p>The class of collections that may be modified.</p>
+ <p>Every mutable collection is required to allow modification by
implementing <code id="MARKER-2-1419">element-setter</code>.</p>
+ <p>The element type of <code><mutable-collection></code> is
<code>indefinite ⇐ <object></code>.</p></dd>
<dt class="Cliche"><span>Operations:</span></dt>
<dd class="Cliche"><p>The class <code><mutable-collection></code>
provides the following operations:</p>
<table class="numbered"><caption><strong>Table 11-25</strong>
Functions on <mutable-collection></caption>
@@ -564,15 +567,16 @@
<a name="HEADING93-982"></a>
<h4 class="item-title"><span class="signature"><code
id="MARKER-2-1420"><mutable-explicit-key-collection></code> </span><span
class="attributes-summary">[Open Abstract Class]</span></h4>
<hr class="item-title" />
- <p class="T1.Text1">The class of ex |
