[m-rev.] diff: improve documentation consistency

[Julien Fischer]

Improve documentation consistency.

Use the non-hyphenated forms of "submodule" and "fully qualified"
throughout.

doc/reference_manual.texi:
doc/user_guide.texi:
compiler/add_type.m:
compiler/deps_map.m:
compiler/module_imports.m:
compiler/pred_table.m:
compiler/process_util.m:
compiler/status.m:
    As above.

Julien.

diff --git a/compiler/add_type.m b/compiler/add_type.m
index fe61348..ba7d247 100644
--- a/compiler/add_type.m
+++ b/compiler/add_type.m
@@ -1025,7 +1025,7 @@ add_type_defn_ctor(Ctor, TypeCtor, TypeCtorModuleName, TVarSet,
          !:Specs = [Spec | !.Specs]
      else
          some [!OtherConsIds] (
-            % Schedule the addition of the fully-qualified cons_id
+            % Schedule the addition of the fully qualified cons_id
              % into the cons_table.
              MainConsId = QualifiedConsIdA,
              !:OtherConsIds = [QualifiedConsIdB],
diff --git a/compiler/deps_map.m b/compiler/deps_map.m
index 126c173..7ee5a54 100644
--- a/compiler/deps_map.m
+++ b/compiler/deps_map.m
@@ -47,8 +47,8 @@
      ;       nested_submodule
      ;       separate_submodule.

-    % Check if a module is a top-level module, a nested sub-module,
-    % or a separate sub-module.
+    % Check if a module is a top-level module, a nested submodule,
+    % or a separate submodule.
      %
  :- func get_submodule_kind(module_name, deps_map) = submodule_kind.

@@ -61,19 +61,19 @@
      % in the deps_map, then we just replace the old entry (presumed to be
      % a dummy entry) with the new one.
      %
-    % This can only occur for sub-modules which have been imported before
+    % This can only occur for submodules which have been imported before
      % their parent module was imported: before reading a module and
      % inserting it into the deps map, we check if it was already there,
      % but when we read in the module, we try to insert not just that module
-    % but also all the nested sub-modules inside that module. If a sub-module
+    % but also all the nested submodules inside that module. If a submodule
      % was previously imported, then it may already have an entry in the
-    % deps_map. However, unless the sub-module is defined both as a separate
-    % sub-module and also as a nested sub-module, the previous entry will be
+    % deps_map. However, unless the submodule is defined both as a separate
+    % submodule and also as a nested submodule, the previous entry will be
      % a dummy entry that we inserted after trying to read the source file
      % and failing.
      %
      % Note that the case where a module is defined as both a separate
-    % sub-module and also as a nested sub-module is caught in
+    % submodule and also as a nested submodule is caught in
      % split_into_submodules.
      %
      % XXX This shouldn't need to be exported.
@@ -240,7 +240,7 @@ insert_into_deps_map(ModuleImports, !DepsMap) :-
      map.set(ModuleName, Deps, !DepsMap).

      % Read a module to determine the (direct) dependencies of that module
-    % and any nested sub-modules it contains. Return the module_and_imports
+    % and any nested submodules it contains. Return the module_and_imports
      % structure for the named module, and each of its nested submodules.
      % If we cannot do better, return a dummy module_and_imports structure
      % for the named module.
diff --git a/compiler/make.module_dep_file.m b/compiler/make.module_dep_file.m
index fb3e3a1..9ff63f3 100644
--- a/compiler/make.module_dep_file.m
+++ b/compiler/make.module_dep_file.m
@@ -239,7 +239,7 @@ do_get_module_dependencies(Globals, RebuildModuleDeps, ModuleName,
                      % 2. copy the standard library lexer.m file to the current
                      %    directory for editing
                      % 3. run mmc --make; it creates lexer.module_dep
-                    % 4. change lexer.m into a sub-module of prog
+                    % 4. change lexer.m into a submodule of prog
                      % 5. run mmc --make again, it no longer works
                      %
                      % The local lexer.module_dep prevents mmc --make finding
@@ -617,7 +617,7 @@ read_module_dependencies_3(Globals, SearchDirs, ModuleName, ModuleDir,
                      SearchDirs),
                  NestedChildren, !Info, !IO),
              ( if some_bad_module_dependency(!.Info, NestedChildren) then
-                Result = error("error in nested sub-modules")
+                Result = error("error in nested submodules")
              else
                  Result = ok
              )
diff --git a/compiler/module_imports.m b/compiler/module_imports.m
index cf01ec1..08ee803 100644
--- a/compiler/module_imports.m
+++ b/compiler/module_imports.m
@@ -47,7 +47,7 @@
      %
      % We also record whether code in the source module whose compilation
      % we are concerned with may refer to items in the read-in module
-    % using non-fully-qualified names, or not.
+    % using non-fully qualified names, or not.
      %
      % What follows in the next two paragraphs is conjecture by wangp,
      % but I (zs) agree that it is likely a correct description of
@@ -62,11 +62,11 @@
      %
      % On the other hand, consider a version of the situation above
      % in which msrc gains access to m1 via an :- import_module declaration.
-    % In that case, if m1 defines an item named f, then a non-fully-qualified
+    % In that case, if m1 defines an item named f, then a non-fully qualified
      % reference to that name *could* refer to that item in m1. If msrc
      % compiled cleanly before, this f must have been resolved to refer
      % to an item defined in some other module, but now that msrc imports m1,
-    % the non-fully-qualified reference to f has become ambiguous.
+    % the non-fully qualified reference to f has become ambiguous.
      % This means that msrc must be recompiled, so that the recompilation
      % may detect and report any such ambiguities.
      %
diff --git a/compiler/pred_table.m b/compiler/pred_table.m
index 131c77b..0cb5f9c 100644
--- a/compiler/pred_table.m
+++ b/compiler/pred_table.m
@@ -223,9 +223,9 @@
      predicate_table::in, predicate_table::out) is det.

      % Equivalent to predicate_table_insert_qual/6, except that only the
-    % fully-qualified version of the predicate will be inserted into the
+    % fully qualified version of the predicate will be inserted into the
      % predicate symbol table. This is useful for creating compiler-generated
-    % predicates which will only ever be accessed via fully-qualified names.
+    % predicates which will only ever be accessed via fully qualified names.
      %
  :- pred predicate_table_insert(pred_info::in, pred_id::out,
      predicate_table::in, predicate_table::out) is det.
@@ -967,7 +967,7 @@ predicate_table_do_insert(Module, Name, Arity, NeedQual, MaybeQualInfo,
          MaybeQualInfo = no,
          AccessibleByPartiallyQualifiedNames = no
      ),
-    % Insert the fully-qualified name into the module.name/arity index.
+    % Insert the fully qualified name into the module.name/arity index.
      insert_into_mna_index(Name, Arity, PredId, Module, !MNA_Index),
      Access = access(AccessibleByUnqualifiedName,
          AccessibleByPartiallyQualifiedNames),
diff --git a/compiler/process_util.m b/compiler/process_util.m
index 35f1245..cc8dd74 100644
--- a/compiler/process_util.m
+++ b/compiler/process_util.m
@@ -9,7 +9,7 @@
  % File: process_util.m.
  % Main author: stayl.
  %
-% Process and signal handling, mainly for use by make.m and its sub-modules.
+% Process and signal handling, mainly for use by make.m and its submodules.
  %
  %-----------------------------------------------------------------------------%
  %-----------------------------------------------------------------------------%
diff --git a/compiler/source_file_map.m b/compiler/source_file_map.m
index 22a8c92..19b5989 100644
--- a/compiler/source_file_map.m
+++ b/compiler/source_file_map.m
@@ -47,7 +47,7 @@
      %
  :- pred have_source_file_map(bool::out, io::di, io::uo) is det.

-    % Return the default fully-qualified source file name.
+    % Return the default fully qualified source file name.
      %
  :- func default_source_file(module_name) = file_name.

diff --git a/compiler/status.m b/compiler/status.m
index 2ee4cc1..61ccf9b 100644
--- a/compiler/status.m
+++ b/compiler/status.m
@@ -145,8 +145,8 @@

      ;       status_abstract_exported
              % Describes a type with only an abstract declaration exported
-            % to non-sub-modules. The definition of the type is exported to
-            % sub-modules.
+            % to non-submodules. The definition of the type is exported to
+            % submodules.

      ;       status_pseudo_exported
              % The converse of pseudo_imported; this means that only the
@@ -154,15 +154,15 @@

      ;       status_exported_to_submodules
              % Defined in the implementation of this module, and thus in
-            % a sense local, but the module contains sub-modules, so the
-            % entity needs to be exported to those sub-modules.
+            % a sense local, but the module contains submodules, so the
+            % entity needs to be exported to those submodules.

      ;       status_local.
              % Defined in the implementation of this module, and the module
-            % does not contain any sub-modules.
+            % does not contain any submodules.

      % Returns yes if the status indicates that the item was in any way exported
-    % -- that is, if it could be used by any other module, or by sub-modules
+    % -- that is, if it could be used by any other module, or by submodules
      % of this module.
      %
      % NOTE: this returns `no' for :- external procedures.
@@ -179,7 +179,7 @@
  :- func old_status_is_exported(old_import_status) = bool.

      % Returns yes if the status indicates that the item was exported
-    % to importing modules (not just to sub-modules).
+    % to importing modules (not just to submodules).
      %
      % NOTE: this returns `no' for :- external procedures.
      %
@@ -192,7 +192,7 @@
  :- func instance_status_is_exported_to_non_submodules(instance_status) = bool.

      % Returns yes if the status indicates that the item was in any way imported
-    % -- that is, if it was defined in some other module, or in a sub-module
+    % -- that is, if it was defined in some other module, or in a submodule
      % of this module. This is the opposite of status_defined_in_this_module.
      %
      % NOTE: this returns `yes' for :- external procedures.
diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
index 746c413..d58e4c0 100644
--- a/doc/reference_manual.texi
+++ b/doc/reference_manual.texi
@@ -1653,10 +1653,10 @@ the line number (integer) of the goal in which the literal appears,
  or -1 if it cannot be determined.

  @item @samp{$module}
-a string representation of the fully-qualified module name.
+a string representation of the fully qualified module name.

  @item @samp{$pred}
-a string containing the fully-qualified predicate or function name and arity.
+a string containing the fully qualified predicate or function name and arity.

  @end table

@@ -5103,7 +5103,7 @@ Future versions of the language may allow these forms.
  @menu
  * The module system::
  * An example module::
-* Sub-modules::
+* Submodules::
  * Module initialisation::
  * Module finalisation::
  * Module-local mutable variables::
@@ -5134,12 +5134,12 @@ or definitions of (sub-)modules.
  An @samp{:- implementation.} declaration indicates
  the start of the module's implementation section.
  Any entities declared in this section are local to the module
-(and its sub-modules, if any) and cannot be used by other modules.
+(and its submodules, if any) and cannot be used by other modules.
  The implementation section must contain definitions
  for all abstract data types, abstract instance declarations,
-functions, predicates, and sub-modules exported by the module,
+functions, predicates, and submodules exported by the module,
  as well as for all local types, type class instances, functions,
-predicates, and sub-modules.
+predicates, and submodules.
  The implementation section can be omitted if it is empty.

  The module may optionally end
@@ -5156,7 +5156,7 @@ using one or more @samp{:- import_module @var{Modules}}
  or @w{@samp{:- use_module @var{Modules}}} declarations,
  in order to make those declarations visible.
  In both cases, @var{Modules}
-is a comma-separated list of fully-qualified module names.
+is a comma-separated list of fully qualified module names.
  These declarations may occur
  either in the interface or the implementation section.
  If the imported entities are used in the interface section,
@@ -5260,56 +5260,56 @@ get([Elem | Queue], Elem, Queue).
  :- end_module queue.
  @end example

- at node Sub-modules
- at section Sub-modules
+ at node Submodules
+ at section Submodules

-As mentioned above, modules may contain sub-modules.
-There are two kinds of sub-modules,
-called nested sub-modules and separate sub-modules;
-the difference is that nested sub-modules
+As mentioned above, modules may contain submodules.
+There are two kinds of submodules,
+called nested submodules and separate submodules;
+the difference is that nested submodules
  are defined in the same source file as the containing module,
-whereas separate sub-modules are defined in separate source files.
-Implementations should support separate compilation of separate sub-modules.
+whereas separate submodules are defined in separate source files.
+Implementations should support separate compilation of separate submodules.

-A module may not contain more than one sub-module with the same name.
+A module may not contain more than one submodule with the same name.

  @menu
-* Nested sub-modules::
-* Separate sub-modules::
+* Nested submodules::
+* Separate submodules::
  * Visibility rules::
  * Implementation bugs and limitations::
  @end menu

- at node Nested sub-modules
- at subsection Nested sub-modules
+ at node Nested submodules
+ at subsection Nested submodules

-Nested sub-modules within a module are delimited by
+Nested submodules within a module are delimited by
  matching @samp{:- module} and @samp{:- end_module} declarations.
-(Note that @samp{:- end_module} for nested sub-modules
+(Note that @samp{:- end_module} for nested submodules
  are mandatory, not optional,
-even if the nested sub-module is the last thing in the source file.
+even if the nested submodule is the last thing in the source file.
  The module name in a @samp{:- module} or @samp{:- end_module}
-declaration for a nested sub-module need not be fully qualified.)
-The sequence of items thus delimited is known as a sub-module item sequence.
+declaration for a nested submodule need not be fully qualified.)
+The sequence of items thus delimited is known as a submodule item sequence.

-The interface and implementation parts of a nested sub-module
-may be specified in two different sub-module declarations.
-If a sub-module item sequence includes an interface section,
-then it is a declaration of that sub-module;
+The interface and implementation parts of a nested submodule
+may be specified in two different submodule declarations.
+If a submodule item sequence includes an interface section,
+then it is a declaration of that submodule;
  if it includes an implementation section,
-then it is a definition of that sub-module;
+then it is a definition of that submodule;
  and if includes both, then it is both declaration and definition.

-It is an error to declare a sub-module twice, or to define it twice.
-It is an error to define a sub-module without declaring it.
+It is an error to declare a submodule twice, or to define it twice.
+It is an error to define a submodule without declaring it.
  As mentioned earlier, it is an error
-to define a sub-module in the interface section of its parent module.
+to define a submodule in the interface section of its parent module.

-If a sub-module is declared but not explicitly defined,
+If a submodule is declared but not explicitly defined,
  then there is an implicit definition
-with an empty implementation section for that sub-module.
+with an empty implementation section for that submodule.
  This empty implementation section will result in an error
-if the interface section of a sub-module contains any of the following:
+if the interface section of a submodule contains any of the following:

  @itemize @bullet
  @item
@@ -5321,18 +5321,18 @@ of that type, inst, mode or typeclass;
  @item
  an abstract declaration of a typeclass instance; or
  @item
-a (doubly, triply, etc) nested sub-module
+a (doubly, triply, etc) nested submodule
  (which perforce has only an interface section, and no implementation section)
  and which contains any of the above.
  @end itemize

- at node Separate sub-modules
- at subsection Separate sub-modules
+ at node Separate submodules
+ at subsection Separate submodules

-Separate sub-modules are declared using
+Separate submodules are declared using
  @samp{:- include_module @var{Modules}} declarations.
  Each @samp{:- include_module} declaration specifies
-a comma-separated list of sub-modules.
+a comma-separated list of submodules.

  @example
  :- include_module @var{Module1}, @var{Module2}, @dots{}, @var{ModuleN}.
@@ -5340,7 +5340,7 @@ a comma-separated list of sub-modules.

  The module names need not be fully qualified.

-Each of the named sub-modules in an @samp{:- include_module} declaration
+Each of the named submodules in an @samp{:- include_module} declaration
  must be defined in a separate source file.
  The mapping between module names and source file names
  is implementation-defined.
@@ -5357,8 +5357,8 @@ using a command such as @samp{mmc -f *.m}.
  with a list of the file names of all the Mercury modules in the program.)
  @end itemize

-The source file of a separate sub-module must contain
-the declaration (interface) and definition (implementation) of the sub-module.
+The source file of a separate submodule must contain
+the declaration (interface) and definition (implementation) of the submodule.
  It must start with a @samp{:- module} declaration
  containing the fully qualified module name,
  followed by the interface and (if necessary) implementation sections,
@@ -5366,19 +5366,19 @@ and it may optionally end with a @samp{:- end_module} declaration.
  (The module name in the @samp{:- end_module} declaration need not be
  fully qualified.)

-The semantics of separate sub-modules
-are identical to those of nested sub-modules.
-The procedure to transform a separate sub-module
-into a nested sub-module is as follows:
+The semantics of separate submodules
+are identical to those of nested submodules.
+The procedure to transform a separate submodule
+into a nested submodule is as follows:

  @enumerate
  @item
  Replace the @samp{:- include_module @var{submodule}} declaration
-with the interface section of the sub-module
+with the interface section of the submodule
  enclosed within @samp{:- module @var{submodule}}
  and @samp{:- end_module @var{submodule}} declarations.
  @item
-Place the implementation section of the sub-module
+Place the implementation section of the submodule
  enclosed within @samp{:- module @var{submodule}}
  and @samp{:- end_module @var{submodule}} declarations
  in the implementation section of the parent module.
@@ -5414,12 +5414,12 @@ is equivalent to

  Any declarations in the parent module,
  including those in the parent module's implementation section,
-are visible in the parent's sub-modules,
-including indirect sub-modules (i.e.@: sub-sub-modules, etc.).
+are visible in the parent's submodules,
+including indirect submodules (i.e.@: sub-submodules, etc.).
  Similarly, declarations in the interfaces of any modules
  imported using an @samp{:- import_module} or a @samp{:- use_module}
  in the parent module
-are visible in the parent's sub-modules, including indirect sub-modules.
+are visible in the parent's submodules, including indirect submodules.

  Declarations in a child module are not visible in the parent module,
  or in ``sibling'' modules (other children of the same parent),
@@ -5428,11 +5428,11 @@ unless the child is explicitly imported using
  an @samp{:- import_module} or @samp{:- use_module} declaration.
  It is an error to import a module without importing all of its parent modules.

-Note that a sub-module for which
+Note that a submodule for which
  the @samp{:- module} or @samp{:- include_module} declaration
  occurs only in the implementation section of the parent module
  may only be imported or used by its parent module
-or by sub-modules of its parent module.
+or by submodules of its parent module.

  As mentioned previously,
  all @samp{:- import_module} and @samp{:- use_module} declarations
@@ -5441,18 +5441,18 @@ must use fully qualified module names.
  @node Implementation bugs and limitations
  @subsection Implementation bugs and limitations

-The current implementation of sub-modules has a couple of minor limitations.
+The current implementation of submodules has a couple of minor limitations.

  @itemize @bullet
  @item
  The compiler sometimes reports spurious errors
-if you define an equivalence type in a sub-module
+if you define an equivalence type in a submodule
  and export it as an abstract type.
  @item
  Using @samp{mmake} to do parallel makes (e.g.@: @samp{mmake --jobs 2})
-doesn't always work correctly if you are using nested sub-modules.
-(The work-around is to use separate sub-modules instead of nested sub-modules,
-i.e.@: to put the sub-modules in separate source files.)
+doesn't always work correctly if you are using nested submodules.
+(The work-around is to use separate submodules instead of nested submodules,
+i.e.@: to put the submodules in separate source files.)
  @end itemize

  @node Module initialisation
@@ -5483,7 +5483,7 @@ is to ensure that @samp{@var{initpredname}/@var{arity}} is invoked
  before the program's @samp{main/2} predicate.
  Initialisation predicates within a module are executed
  in the order in which they are specified,
-although no order may be assumed between different modules or sub-modules.
+although no order may be assumed between different modules or submodules.
  Initialisation predicates are only invoked
  after any initialisation required by the Mercury standard library.

@@ -5524,7 +5524,7 @@ is to ensure that @samp{@var{finalpredname}/@var{arity}} is invoked
  after the program's @samp{main} predicate.
  Finalisation predicates within a module
  are executed in the order in which they are specified,
-although no order may be assumed between different modules or sub-modules.
+although no order may be assumed between different modules or submodules.
  Any finalisation required by the Mercury standard library
  will always occur after any finalisation predicates have been invoked.

@@ -5655,7 +5655,7 @@ together with either of the @samp{trailed} or @samp{constant} attributes.

  It is an error for a @samp{mutable} directive
  to appear in the interface section of a module.
-The usual visibility rules for sub-modules
+The usual visibility rules for submodules
  apply to the mutable variable access predicates.

  For the purposes of determining
@@ -11743,7 +11743,7 @@ in the implementation section of a module.

  A @samp{pragma require_feature_set} affects
  only the module in which it occurs;
-in particular it does not affect any sub-modules.
+in particular it does not affect any submodules.

  If a module contains multiple @samp{pragma require_feature_set} declarations,
  then the implementation should emit an error
diff --git a/doc/user_guide.texi b/doc/user_guide.texi
index 9122127..6d2468f 100644
--- a/doc/user_guide.texi
+++ b/doc/user_guide.texi
@@ -311,7 +311,7 @@ where @var{module} is the name of the Mercury module defined in
  @file{@var{filename}.m}.
  It also will leave the intermediate C code in a file called
  @file{@var{module}.c}.
-If the source file contains nested modules, then each sub-module will get
+If the source file contains nested modules, then each submodule will get
  compiled to separate C and object files.

  Before you can compile a module,
@@ -951,7 +951,7 @@ and, on many platforms, it supports shared object libraries.
  @section Writing libraries

  A Mercury library is identified by a top-level module,
-which should contain all of the modules in that library as sub-modules.
+which should contain all of the modules in that library as submodules.
  It may be as simple as this @file{mypackage.m} file:

  @example
@@ -963,7 +963,7 @@ It may be as simple as this @file{mypackage.m} file:
  @end example

  @noindent
-This defines a module @samp{mypackage} containing sub-modules
+This defines a module @samp{mypackage} containing submodules
  @samp{mypackage.foo}, @samp{mypackage.bar}, and @samp{mypackage.baz}.

  It is also possible to build libraries of unrelated modules,
@@ -990,7 +990,7 @@ Alternatively, the library could of course just export something,
  such as a predicate that returns its version number.

  Generally it is better style for each library
-to consist of a single module which encapsulates its sub-modules,
+to consist of a single module which encapsulates its submodules,
  as in the first example,
  rather than just a group of unrelated modules,
  as in the second example.
@@ -7168,7 +7168,7 @@ Write the unqualified version of the short interface to
  @itemx --make-private-interface
  @findex --make-priv-int
  @findex --make-private-interface
-Write the module's private interface (used for compiling nested sub-modules)
+Write the module's private interface (used for compiling nested submodules)
  to @file{@var{module}.int0}.

  @sp 1