diff: rearrange chapters in user guide

[Fergus Henderson]

The diff below shows only the changed text;
it doesn't include the large chunks of text that
were just moved around unchanged.

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

Estimated hours taken: 0.4

doc/user_guide.texi:
	Move the "Using Prolog" chapter to the very end, and
	update some obsolete documentation referring to it --
	now that we have `mdb', people shouldn't need to use Prolog.
	Move the "Debugging" chapter to before the "Profiling"
	chapter.

Index: user_guide.texi
===================================================================
RCS file: /home/mercury1/repository/mercury/doc/user_guide.texi,v
retrieving revision 1.150
diff -u -u -r1.150 user_guide.texi
--- user_guide.texi	1998/11/15 16:47:38	1.150
+++ user_guide.texi	1998/11/15 17:14:21
@@ -77,15 +77,15 @@
 * Filenames::       File naming conventions
 * Using mmc::       Compiling and linking programs with the Mercury compiler
 * Running::         Execution of programs built with the Mercury compiler
-* Using Prolog::    Building and debugging Mercury programs with Prolog
 * Using Mmake::     ``Mercury Make'', a tool for building Mercury programs
 * Libraries::       Creating and using libraries of Mercury modules
+* Debugging::       The Mercury debugger @samp{mdb}
 * Profiling::       The Mercury profiler @samp{mprof}, a tool for analyzing
                     program performance
 * Invocation::      List of options for the Mercury compiler
-* Debugging::       The Mercury debugger @samp{mdb}
 * Environment::     Environment variables used by the compiler and utilities
 * C compilers::     How to use a C compiler other than GNU C
+* Using Prolog::    Building and debugging Mercury programs with Prolog
 @end menu
 @end ifinfo
 
@@ -97,30 +97,13 @@
 how to use @samp{mmake}, the ``Mercury make'' program,
 a tool built on top of ordinary or GNU make
 to simplify the handling of Mercury programs;
-and how to use Prolog to debug Mercury programs.
+how to use @samp{mdb}, the Mercury debugger;
+and how to use @samp{mprof}, the Mercury profiler.
 
 We strongly recommend that programmers use @samp{mmake} rather
 than invoking @samp{mmc} directly, because @samp{mmake} is generally
 easier to use and avoids unnecessary recompilation.
 
-Since the Mercury implementation is essentially a native-code compiler
-which happens to compile via GNU C, not an interpreter,
-debugging of compiled Mercury programs would require
-a dedicated Mercury debugger program - or at least some
-significant extensions to gdb.  It would also require
-the Mercury compiler to arrange for the object
-code to contain suitable debugging information.
-Although it is possible to debug the intermediate C code, this is
-not productive, since the intermediate C code is extremely low-level
-and bears little resemblance to the source code.
-As an alternative, Mercury programmers may wish to use a Prolog system
-to execute their Mercury programs in order to gain access to this facility.
-The feasibility of this technique is dependent upon the program
-being written in the intersection of the Prolog and Mercury languages,
-which is possible because the two languages have almost the same syntax.
-The Mercury implementation allows you to run a Mercury program
-using NU-Prolog or SICStus Prolog (@pxref{Using Prolog}).
-
 @node Filenames
 @chapter File naming conventions
 
@@ -346,9 +329,22 @@
 @node Using Prolog
 @chapter Using Prolog
 
-Since the current Mercury implementation does not yet provide any
-useful support for debugging, we recommend that you use a Prolog
-system for debugging your Mercury programs.
+Earlier versions of the Mercury implementation did not provide
+a Mercury debugger; instead, they provided a way to build Mercury
+programs using a Prolog system, so that you could use the Prolog
+debugger.  This chapter documents how to do that.
+Now that we have a native Mercury debugger, the ability to
+build Mercury programs using a Prolog system is probably not
+very useful anymore.  So for most purposes this chapter is
+really of historical interest only.  We encourage all but
+the most avid of readers to skip the rest of this chapter.
+
+The feasibility of this technique is dependent upon the program
+being written in the intersection of the Prolog and Mercury languages,
+which is possible because the two languages have almost the same syntax.
+The Mercury implementation allows you to run a Mercury program
+using NU-Prolog or SICStus Prolog.
+
 However, there is no point in using a Prolog debugger to track down a bug
 that can be detected statically by the Mercury compiler.
 The command

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.