More C++ Modules documentation updates

1 files changed, 4 insertions, 15 deletions

diff --git a/doc/manual.cli b/doc/manual.cli
index 8071b1f..8fd23a7 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -870,7 +870,7 @@ in a module's purview \i{belongs} to said module. For example:
 \
 #include <string>                // Not in purview.
 
-export module hello.core;
+export module hello.core;        // Start of purview.
 
 void
 say_hello (const std::string&);  // In purview.
@@ -938,19 +938,8 @@ decorating the non-exported symbols with a module name.
 
 This ownership model has one important backwards-compatibility implication: a
 library built with modules enabled can be linked to a program that still uses
-headers. And vice versa: we can build a module for a library that only uses
-headers. For example, if our compiler does not provide a module for the
-standard library, we should be able to build our own:
-
-\
-export module std.core;
-
-export
-{
-  #include <string>
-  //...
-}
-\
+headers. And vice versa: we can build and use a module for a library that was
+built with headers.
 
 What about the preprocessor? Modules do not export preprocessor macros,
 only C++ names. A macro defined in the module interface unit cannot affect
@@ -1025,7 +1014,7 @@ One way to think of a re-export is \i{as-if} an import of a module also
 \"injects\" all the imports said module re-exports, recursively. That's
 essentially how most compilers implement it.
 
-Module re-export is the mechanism of assembling bigger modules out of
+Module re-export is the mechanism for assembling bigger modules out of
 submodules. As an example, let's say we had the \c{hello.core},
 \c{hello.basic}, and \c{hello.extra} modules. To make life easier for users
 that want to import all of them we can create the \c{hello} module that