doc/concepts.tex: Fix misformatting.

[sod] / doc / concepts.tex

diff --git a/doc/concepts.tex b/doc/concepts.tex
index 6ec27b9..c4bcf61 100644 (file)
--- a/doc/concepts.tex
+++ b/doc/concepts.tex
@@ -144,9 +144,9 @@ This partial order is not quite sufficient for our purposes.  For each class
 $C$, we shall need to extend it into a total order on $C$'s superclasses.
 This calculation is called \emph{superclass linearization}, and the result is
 a \emph{class precedence list}, which lists each of $C$'s superclasses
 $C$, we shall need to extend it into a total order on $C$'s superclasses.
 This calculation is called \emph{superclass linearization}, and the result is
 a \emph{class precedence list}, which lists each of $C$'s superclasses

-exactly once.  If a superclass $B$ precedes (resp.\ follows) some other
-superclass $A$ in $C$'s class precedence list, then we say that $B$ is a more
-(resp.\ less) \emph{specific} superclass of $C$ than $A$ is.
+exactly once.  If a superclass $B$ precedes or follows some other superclass
+$A$ in $C$'s class precedence list, then we say that $B$ is respectively a
+more or less \emph{specific} superclass of $C$ than $A$.

 
 The superclass linearization algorithm isn't fixed, and extensions to the
 translator can introduce new linearizations for special effects, but the
 
 The superclass linearization algorithm isn't fixed, and extensions to the
 translator can introduce new linearizations for special effects, but the


@@ -159,8 +159,8 @@ following properties are expected to hold.
   list, i.e., $B$ is a more specific superclass of $C$ than $A$ is.
 \end{itemize}
 The default linearization algorithm used in Sod is the \emph{C3} algorithm,
   list, i.e., $B$ is a more specific superclass of $C$ than $A$ is.
 \end{itemize}
 The default linearization algorithm used in Sod is the \emph{C3} algorithm,

-which has a number of good properties described in~\cite{Barrett:1996:MSL}.
-It works as follows.
+which has a number of good properties described
+in~\cite{barrett-1996:monot-super-linear-dylan}.  It works as follows.

 \begin{itemize}
 \item A \emph{merge} of some number of input lists is a single list
   containing each item that is in any of the input lists exactly once, and no
 \begin{itemize}
 \item A \emph{merge} of some number of input lists is a single list
   containing each item that is in any of the input lists exactly once, and no


@@ -263,8 +263,9 @@ It works as follows.
 
   \end{itemize}
 
 
   \end{itemize}
 

-  (This example combines elements from \cite{Barrett:1996:MSL} and
-  \cite{Ducournau:1994:PMM}.)
+  (This example combines elements from
+  \cite{barrett-1996:monot-super-linear-dylan} and
+  \cite{ducournau-1994:monot-multip-inher-linear}.)

 \end{example}
 
 \subsubsection{Class links and chains}
 \end{example}
 
 \subsubsection{Class links and chains}


@@ -473,12 +474,12 @@ There are three main cases to distinguish.
   a lookup at runtime to find the appropriate offset by which to adjust the
   pointer.  The conversion can be performed using the appropriate generated
   upcast macro (see below); the general case is handled by the macro
   a lookup at runtime to find the appropriate offset by which to adjust the
   pointer.  The conversion can be performed using the appropriate generated
   upcast macro (see below); the general case is handled by the macro

-  \descref{SOD_XCHAIN}{mac}.
+  \descref{mac}{SOD_XCHAIN}.

 \item If $B$ is a subclass of~$C$ then the conversion is a \emph{downcast};
   otherwise the conversion is a~\emph{cross-cast}.  In either case, the
   conversion can fail: the object in question might not be an instance of~$B$
 \item If $B$ is a subclass of~$C$ then the conversion is a \emph{downcast};
   otherwise the conversion is a~\emph{cross-cast}.  In either case, the
   conversion can fail: the object in question might not be an instance of~$B$

-  after all.  The macro \descref{SOD_CONVERT}{mac} and the function
-  \descref{sod_convert}{fun} perform general conversions.  They return a null
+  after all.  The macro \descref{mac}{SOD_CONVERT} and the function
+  \descref{fun}{sod_convert} perform general conversions.  They return a null

   pointer if the conversion fails.  (These are therefore your analogue to the
   \Cplusplus\ @|dynamic_cast<>| operator.)
 \end{itemize}
   pointer if the conversion fails.  (These are therefore your analogue to the
   \Cplusplus\ @|dynamic_cast<>| operator.)
 \end{itemize}


@@ -607,9 +608,9 @@ message.  The method combination determines which direct method rôles are
 acceptable, and, for each rôle, the appropriate argument lists and return
 types.
 
 acceptable, and, for each rôle, the appropriate argument lists and return
 types.
 

-One direct method, $M$, is said to be more (resp.\ less) \emph{specific} than
+One direct method, $M$, is said to be more or less \emph{specific} than

 another, $N$, with respect to a receiving class~$C$, if the class defining
 another, $N$, with respect to a receiving class~$C$, if the class defining

-$M$ is a more (resp.\ less) specific superclass of~$C$ than the class
+$M$ is respectively a more or less specific superclass of~$C$ than the class

 defining $N$.
 
 \subsubsection{The standard method combination}
 defining $N$.
 
 \subsubsection{The standard method combination}


@@ -695,7 +696,7 @@ entry functions.
       node [above right = 0mm and -8mm]
       {$\vcenter{\hbox{\Huge\textcolor{red}{!}}}
         \vcenter{\hbox{\begin{tabular}[c]{l}
       node [above right = 0mm and -8mm]
       {$\vcenter{\hbox{\Huge\textcolor{red}{!}}}
         \vcenter{\hbox{\begin{tabular}[c]{l}

-                         \textsf{next_method} \\
+                         @|next_method| \\

                          pointer is null
                        \end{tabular}}}$};
 
                          pointer is null
                        \end{tabular}}}$};
 


@@ -820,7 +821,7 @@ The aggregating method combinations provided are as follows.
 \item[progn] The message must return @|void|.  The applicable primary methods
   are simply invoked in turn, most specific first.
 \item[sum] The message must return a numeric type.\footnote{%
 \item[progn] The message must return @|void|.  The applicable primary methods
   are simply invoked in turn, most specific first.
 \item[sum] The message must return a numeric type.\footnote{%

-    The Sod translator does not check this, since it doesn't have enough
+    The Sod translator doesn't check this, since it doesn't have enough

     insight into @|typedef| names.} %
   The applicable primary methods are invoked in turn, and their return values
   added up.  The final result is the sum of the individual values.
     insight into @|typedef| names.} %
   The applicable primary methods are invoked in turn, and their return values
   added up.  The final result is the sum of the individual values.


@@ -924,14 +925,14 @@ Construction of a new instance of a class involves three steps.
   instance's slots, and maybe links it into any external data structures as
   necessary.
 \end{enumerate}
   instance's slots, and maybe links it into any external data structures as
   necessary.
 \end{enumerate}

-The \descref{SOD_DECL}[macro]{mac} handles constructing instances with
+The \descref{mac}{SOD_DECL}[macro] handles constructing instances with

 automatic storage duration (`on the stack').  Similarly, the
 automatic storage duration (`on the stack').  Similarly, the

-\descref{SOD_MAKE}[macro]{mac} and the \descref{sod_make}{fun} and
-\descref{sod_makev}{fun} functions construct instances allocated from the
+\descref{mac}{SOD_MAKE}[macro] and the \descref*{fun}{sod_make} and
+\descref{fun}{sod_makev} functions construct instances allocated from the

 standard @|malloc| heap.  Programmers can add support for other allocation
 standard @|malloc| heap.  Programmers can add support for other allocation

-strategies by using the \descref{SOD_INIT}[macro]{mac} and the
-\descref{sod_init}{fun} and \descref{sod_initv}{fun} functions, which package
-up imprinting and initialization.
+strategies by using the \descref{mac}{SOD_INIT}[macro] and the
+\descref*{fun}{sod_init} and \descref{fun}{sod_initv} functions, which
+package up imprinting and initialization.

 
 \subsubsection{Allocation}
 Instances of most classes (specifically including those classes defined by
 
 \subsubsection{Allocation}
 Instances of most classes (specifically including those classes defined by


@@ -1100,9 +1101,9 @@ steps.
 Teardown alone, for objects which require special deallocation, or for which
 deallocation occurs automatically (e.g., instances with automatic storage
 duration, or instances whose storage will be garbage-collected), is performed
 Teardown alone, for objects which require special deallocation, or for which
 deallocation occurs automatically (e.g., instances with automatic storage
 duration, or instances whose storage will be garbage-collected), is performed

-using the \descref{sod_teardown}[function]{fun}.  Destruction of instances
+using the \descref{fun}{sod_teardown}[function].  Destruction of instances

 allocated from the standard @|malloc| heap is done using the
 allocated from the standard @|malloc| heap is done using the

-\descref{sod_destroy}[function]{fun}.
+\descref{fun}{sod_destroy}[function].

 
 \subsubsection{Teardown}
 Details of teardown are necessarily class-specific, but typically it
 
 \subsubsection{Teardown}
 Details of teardown are necessarily class-specific, but typically it


@@ -1127,7 +1128,7 @@ counting system, as follows.
     [role = around]                                             \\
     int obj.teardown()                                          \\
     \{                                                          \\ \ind
     [role = around]                                             \\
     int obj.teardown()                                          \\
     \{                                                          \\ \ind

-      if (--\,--me@->ref.nref) return (1);                      \\
+      if (@--me@->ref.nref) return (1);                           \\

       else return (CALL_NEXT_METHOD);                         \-\\
     \}                                                        \-\\
   \}
       else return (CALL_NEXT_METHOD);                         \-\\
     \}                                                        \-\\
   \}


@@ -1160,7 +1161,7 @@ class.
 The code which makes the decision to destroy an object may often not be aware
 of the object's direct class.  Low-level details of deallocation often
 require the proper base address of the instance's storage, which can be
 The code which makes the decision to destroy an object may often not be aware
 of the object's direct class.  Low-level details of deallocation often
 require the proper base address of the instance's storage, which can be

-determined using the \descref{SOD_INSTBASE}[macro]{mac}.
+determined using the \descref{mac}{SOD_INSTBASE}[macro].

 
 %%%--------------------------------------------------------------------------
 \section{Metaclasses} \label{sec:concepts.metaclasses}
 
 %%%--------------------------------------------------------------------------
 \section{Metaclasses} \label{sec:concepts.metaclasses}


@@ -1277,7 +1278,7 @@ functions.
 Metaobject classes are chosen in a fairly standard way.
 \begin{itemize}
 \item All metaobject definitions support a symbol-valued property, usually
 Metaobject classes are chosen in a fairly standard way.
 \begin{itemize}
 \item All metaobject definitions support a symbol-valued property, usually

-  named @|@<thing>_class| (e.g., @|slot_class|, @|method_class|), which sets
+  named @|@<thing>{}_class| (e.g., @|slot_class|, @|method_class|), which sets

   the metaobject class explicitly.  (The class for a class metaobject is
   taken from the @|lisp_class| property, because @|class_class| seems less
   meaningful.)
   the metaobject class explicitly.  (The class for a class metaobject is
   taken from the @|lisp_class| property, because @|class_class| seems less
   meaningful.)