trivial diff: Use @xref properly in reference manual

Mark Anthony BROWN dougl at cs.mu.OZ.AU
Mon Mar 15 19:08:55 AEDT 1999


Estimated hours taken: 1.5

doc/reference_manual.texi:

	Fix some incorrect usages of @ref, @xref and @pxref.


Index: doc/reference_manual.texi
===================================================================
RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
retrieving revision 1.132
diff -u -t -r1.132 reference_manual.texi
--- reference_manual.texi	1999/03/13 01:29:14	1.132
+++ reference_manual.texi	1999/03/15 08:00:20
@@ -768,7 +768,7 @@
 @noindent
 where DCGVar0 and DCGVar1 are fresh variables,
 and Goal is the result of @samp{DCG-transform(DCGVar0, DCGVar1, DCGGoal)}
-where DCG-transform is the function specified in @pxref{DCG-goals}.
+where DCG-transform is the function specified in @ref{DCG-goals}.
 @xref{Higher-order}.
 
 A higher-order function application is a compound term of one
@@ -3414,7 +3414,7 @@
 for the specified Mercury procedure; instead, any calls to that
 procedure will be executed by calling the C function named
 @var{C_Name}.  The @var{Attributes} argument is optional; if present,
-it specifies properties of the given C function (see @pxref{C code attributes}).
+it specifies properties of the given C function (@pxref{C code attributes}).
 
 For example, the following code imports the C function @samp{cos()}
 as the Mercury function @samp{cos/1}:
@@ -3426,7 +3426,7 @@
 
 The interface to the C function for a given Mercury procedure is
 determined as follows.  Mercury types are converted to C types
-according to the rules in @xref{Passing data to and from C}.
+according to the rules in @ref{Passing data to and from C}.
 Mercury arguments declared with input modes are passed by value to the
 C function.  For output arguments, the Mercury implementation will pass
 to the C function an address in which to store the result. 
@@ -3454,7 +3454,7 @@
 You may not give a @samp{pragma import} declaration for a procedure
 with determinism @samp{nondet} or @samp{multi}.
 (It is however possible to define a @samp{nondet} or @samp{multi} procedure
-using @samp{pragma c_code} -- see @pxref{Nondet pragma c_code}).
+using @samp{pragma c_code} -- @pxref{Nondet pragma c_code}).
 
 @node pragma c_code
 @subsubsection pragma c_code
@@ -3481,7 +3481,7 @@
 (@var{Var1}, @var{Var2}, @dots{}, and @var{Var})
 directly by name.  These variables will have C types corresponding
 to their Mercury types, as determined by the rules specified in
- at xref{Passing data to and from C}.
+ at ref{Passing data to and from C}.
 
 The C code fragment may declare local variables, but it should not
 declare any labels or static variables unless there is also a Mercury
@@ -3857,7 +3857,7 @@
 The interface to a Mercury procedure is determined as follows.
 (The rules here are just the converse of the rules for @samp{pragma import}).
 Mercury types are converted to C types according to the rules in
- at xref{Passing data to and from C}.
+ at ref{Passing data to and from C}.
 Input arguments are passed by value.  For output arguments, the
 caller must pass the address in which to store the result.
 If the Mercury procedure can fail, then its C interface function
@@ -4759,8 +4759,9 @@
 @c XXX give an example
 
 For more information on tabling, see K. Sagonas's PhD thesis
+ at c XXX this citation doesn't come out properly in DVI format
 @cite{The SLG-WAM: A Search-Efficient Engine for Well-Founded Evaluation
-of Normal Logic Programs.} @ref{[4]}.
+of Normal Logic Programs.} @xref{[4]}.
 The operational semantics of procedures with a @samp{pragma minimal_model}
 declaration corresponds to what Sagonas calls ``SLGd resolution''.
 
@@ -4770,8 +4771,9 @@
 The Mercury implementation uses a technique based on copying
 relevant parts of the stack to the heap when delaying goals,
 similar to the one described in
+ at c XXX this citation doesn't come out properly in DVI format
 @cite{CAT: the copying approach to tabling},
-by B. Demoen and K. Sagonas @ref{[5]}.
+by B. Demoen and K. Sagonas.  @xref{[5]}.
 This ensures that code which does not use tabling does not pay any
 runtime overheads from the more complicated execution mechanism
 required by (minimal model) tabling.
@@ -4797,14 +4799,18 @@
 The compiler includes a termination analyser which can be used to prove 
 termination of predicates and functions.  Details of the analysis is
 available in ``Termination Analysis for Mercury'' by Chris Speirs, Zoltan
-Somogyi and Harald Sondergaard @ref{[1]}.
+Somogyi and Harald Sondergaard.  @xref{[1]}.
+ at c XXX this citation doesn't come out properly in DVI format
 
 The analysis is based around an algorithm proposed by Gerhard Groger
 and Lutz Plumer in their paper ``Handling of mutual recursion in
-automatic termination proofs for logic programs.'' @ref{[2]}.
+automatic termination proofs for logic programs.'' @xref{[2]}.
+ at c XXX this citation doesn't come out properly in DVI format
 
 For an introduction to termination analysis for logic programs, please
-refer to ``Termination Analysis for Logic Programs'' by Chris Speirs @ref{[3]}.
+refer to ``Termination Analysis for Logic Programs'' by Chris Speirs.
+ at c XXX this citation doesn't come out properly in DVI format
+ at xref{[3]}.
 
 Information about the termination properties of a predicate or function
 can be given to the compiler.  Pragmas are also available to require


-- 
Mark Brown  (dougl at cs.mu.oz.au)       )O+   |  For Microsoft to win,
MEngSc student,                             |  the customer must lose
Dept of Computer Science, Melbourne Uni     |          -- Eric S. Raymond



More information about the developers mailing list