+ Define @<from> as a function of one argument, so that @|(@<from> @<thing>)|
+ is equivalent to @|(@<to> @<thing>)|. If @<read-only-flag> is nil (the
+ default), then also define @|(setf @<from>)| so that @|(setf (@<from>
+ @<thing>) @<value>)| is equivalent to @|(setf (@<to> @<thing>) @<value>)|.
+
+ In a @|defstruct| form, the accessor function names are constructed based
+ on the structure name and slot names. The structure name and accessor
+ names are part of the exported interface, but the slot names ideally
+ shouldn't be. This causes a problem when the slot name which will lead to
+ the right accessor is already an external symbol in some package. You can
+ solve this problem by choosing an internal name for the symbol, and then
+ using this macro to define an accessor function with the name that you
+ want, in terms of the accessor that @|defstruct| made.
+\end{describe}
+
+\begin{describe}{fun}
+ {distinguished-point-shortest-paths @<root> @<neighbours-func>
+ @> @<list>}
+ Calculate the shortest path from the @<root> to each node reachable from it
+ in a directed graph. The nodes of the graph can be any kind of object;
+ they will be compared using @|eql|.
+
+ The @<neighbours-func> should be a function which, given a node~$v$ as its
+ only argument, returns a list of cons cells @|($v'$ . $c'$)|, one for each
+ node~$v'$ adjacent to $v$, indicating the cost $c'$ of traversing the arc
+ from $v$ to $v'$.
+
+ The return value is a list of cons cells @|($c$ . $p$)|, where $p$ is list
+ of nodes, in reverse order, along a path from the @<root> to some other
+ node, and $c$ is the total cost of traversing this path. (Therefore @|(car
+ $p$)| is the destination node, and @|(car (last $p$))| is always the
+ @<root> itself.)
+
+ The function runs in $O(n^2)$ time, where $n$ is the number of nodes
+ reachable from the @<root>. Currently, it uses an algorithm due to Edsger
+ Dijkstra.
+\end{describe}
+
+
+\subsection{Other exported symbols}
+
+\begin{describe}{sym}{int}
+ The symbol @|int| is exported by the @|sod-utilities| package, without
+ giving it any particular meaning. This is done because it's given
+ non-conflicting meanings by two different packages, and it's more
+ convenient for user code not to have to deal with an unnecessary symbol
+ conflict. Specifically, the @|sod| package wants to define it as a C type
+ specifier, see \descref{cls}{simple-c-type}; and @|optparse| wants to
+ define it as an option handler, see \descref{opt}{int}.