Update Erlang Reference Manual

Language cleaned up by the technical writers xsipewe and tmanevik
from Combitech. Proofreading and corrections by Hans Bolinder.

1 files changed, 52 insertions, 37 deletions

diff --git a/system/doc/reference_manual/processes.xml b/system/doc/reference_manual/processes.xml
index 95ae0672ec..32af6d4480 100644
--- a/system/doc/reference_manual/processes.xml
+++ b/system/doc/reference_manual/processes.xml
@@ -4,7 +4,7 @@
 <chapter>
   <header>
     <copyright>
-      <year>2003</year><year>2013</year>
+      <year>2003</year><year>2015</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -32,8 +32,8 @@
   <section>
     <title>Processes</title>
     <p>Erlang is designed for massive concurrency. Erlang processes are
-      light-weight (grow and shrink dynamically) with small memory
-      footprint, fast to create and terminate and the scheduling
+      lightweight (grow and shrink dynamically) with small memory
+      footprint, fast to create and terminate, and the scheduling
       overhead is low.</p>
   </section>
 
@@ -46,10 +46,10 @@ spawn(Module, Name, Args) -> pid()
   Args = [Arg1,...,ArgN]
     ArgI = term()</pre>
     <p><c>spawn</c> creates a new process and returns the pid.</p>
-    <p>The new process will start executing in
-      <c>Module:Name(Arg1,...,ArgN)</c> where the arguments is
+    <p>The new process starts executing in
+      <c>Module:Name(Arg1,...,ArgN)</c> where the arguments are
       the elements of the (possible empty) <c>Args</c> argument list.</p>
-    <p>There exist a number of other <c>spawn</c> BIFs, for example
+    <p>There exist a number of other <c>spawn</c> BIFs, for example,
       <c>spawn/4</c> for spawning a process at another node.</p>
   </section>
 
@@ -60,18 +60,25 @@ spawn(Module, Name, Args) -> pid()
       atom and is automatically unregistered if the process terminates:</p>
     <table>
       <row>
+        <cell align="left" valign="middle"><em>BIF</em></cell>
+        <cell align="left" valign="middle"><em>Description</em></cell>
+      </row>
+      <row>
         <cell align="left" valign="middle"><c>register(Name, Pid)</c></cell>
         <cell align="left" valign="middle">Associates the name <c>Name</c>, an atom, with the process <c>Pid</c>.</cell>
       </row>
       <row>
         <cell align="left" valign="middle"><c>registered()</c></cell>
-        <cell align="left" valign="middle">Returns a list of names which have been registered using<c>register/2</c>.</cell>
+        <cell align="left" valign="middle">Returns a list of names that
+        have been registered using <c>register/2</c>.</cell>
       </row>
       <row>
         <cell align="left" valign="middle"><c>whereis(Name)</c></cell>
-        <cell align="left" valign="middle">Returns the pid registered under <c>Name</c>, or<c>undefined</c>if the name is not registered.</cell>
+        <cell align="left" valign="middle">Returns the pid registered
+        under <c>Name</c>, or <c>undefined </c>if the name is not
+        registered.</cell>
       </row>
-      <tcaption>Name Registration BIFs.</tcaption>
+      <tcaption>Name Registration BIFs</tcaption>
     </table>
   </section>
 
@@ -79,22 +86,27 @@ spawn(Module, Name, Args) -> pid()
     <marker id="term"></marker>
     <title>Process Termination</title>
     <p>When a process terminates, it always terminates with an
-      <em>exit reason</em>. The reason may be any term.</p>
+      <em>exit reason</em>. The reason can be any term.</p>
     <p>A process is said to terminate <em>normally</em>, if the exit
       reason is the atom <c>normal</c>. A process with no more code to
       execute terminates normally.</p>
-    <p>A process terminates with exit reason <c>{Reason,Stack}</c>
+    <p>A process terminates with an exit reason <c>{Reason,Stack}</c>
       when a run-time error occurs. See
-      <seealso marker="errors#exit_reasons">Error and Error Handling</seealso>.</p>
-    <p>A process can terminate itself by calling one of the BIFs
-      <c>exit(Reason)</c>, 
-      <c>erlang:error(Reason)</c>, <c>erlang:error(Reason, Args)</c>,
-      <c>erlang:fault(Reason)</c> or <c>erlang:fault(Reason, Args)</c>. 
-      The process then terminates with reason <c>Reason</c> for
+      <seealso marker="errors#exit_reasons">Exit Reasons</seealso>.</p>
+    <p>A process can terminate itself by calling one of the
+       following BIFs:</p>
+    <list type="bulleted">
+      <item><c>exit(Reason)</c></item>
+      <item><c>erlang:error(Reason)</c></item>
+      <item><c>erlang:error(Reason, Args)</c></item>
+      <item><c>erlang:fault(Reason)</c></item>
+      <item><c>erlang:fault(Reason, Args)</c></item>
+    </list>
+    <p>The process then terminates with reason <c>Reason</c> for
       <c>exit/1</c> or <c>{Reason,Stack} for the others</c>.</p>
-    <p>A process may also be terminated if it receives an exit signal
+    <p>A process can also be terminated if it receives an exit signal
       with another exit reason than <c>normal</c>, see
-      <seealso marker="#errors">Error Handling</seealso> below.</p>
+      <seealso marker="#errors">Error Handling</seealso>.</p>
   </section>
 
   <section>
@@ -113,35 +125,38 @@ spawn(Module, Name, Args) -> pid()
     <title>Links</title>
     <p>Two processes can be <em>linked</em> to each other. A link
       between two processes <c>Pid1</c> and <c>Pid2</c> is created
-      by <c>Pid1</c> calling the BIF <c>link(Pid2)</c> (or vice versa).
+      by <c>Pid1</c> calling the BIF <c>link(Pid2)</c> (or conversely).
       There also exist a number of <c>spawn_link</c> BIFs, which spawn
       and link to a process in one operation.</p>
     <p>Links are bidirectional and there can only be one link between
       two processes. Repeated calls to <c>link(Pid)</c> have no effect.</p>
     <p>A link can be removed by calling the BIF <c>unlink(Pid)</c>.</p>
     <p>Links are used to monitor the behaviour of other processes, see
-      <seealso marker="#errors">Error Handling</seealso> below.</p>
+      <seealso marker="#errors">Error Handling</seealso>.</p>
   </section>
 
   <section>
     <marker id="errors"></marker>
     <title>Error Handling</title>
     <p>Erlang has a built-in feature for error handling between
-      processes. Terminating processes will emit exit signals to all
-      linked processes, which may terminate as well or handle the exit
+      processes. Terminating processes emit exit signals to all
+      linked processes, which can terminate as well or handle the exit
       in some way. This feature can be used to build hierarchical
       program structures where some processes are supervising other
-      processes, for example restarting them if they terminate
+      processes, for example, restarting them if they terminate
       abnormally.</p>
-    <p>Refer to OTP Design Principles for more information about
-      OTP supervision trees, which uses this feature.</p>
+    <p>See <seealso marker="doc/design_principles">
+      OTP Design Principles</seealso> for more information about
+      OTP supervision trees, which use this feature.</p>
 
     <section>
       <title>Emitting Exit Signals</title>
-      <p>When a process terminates, it will terminate with an <em>exit reason</em> as explained in <seealso marker="#term">Process Termination</seealso> above. This exit reason is emitted in
+      <p>When a process terminates, it terminates with an
+        <em>exit reason</em> as explained in <seealso marker="#term">
+        Process Termination</seealso>. This exit reason is emitted in
         an <em>exit signal</em> to all linked processes.</p>
       <p>A process can also call the function <c>exit(Pid,Reason)</c>.
-        This will result in an exit signal with exit reason
+        This results in an exit signal with exit reason
         <c>Reason</c> being emitted to <c>Pid</c>, but does not affect
         the calling process.</p>
     </section>
@@ -156,14 +171,14 @@ spawn(Module, Name, Args) -> pid()
       <p>A process can be set to trap exit signals by calling:</p>
       <pre>
 process_flag(trap_exit, true)</pre>
-      <p>When a process is trapping exits, it will not terminate when
+      <p>When a process is trapping exits, it does not terminate when
         an exit signal is received. Instead, the signal is transformed
-        into a message <c>{'EXIT',FromPid,Reason}</c> which is put into
-        the mailbox of the process just like a regular message.</p>
+        into a message <c>{'EXIT',FromPid,Reason}</c>, which is put into
+        the mailbox of the process, just like a regular message.</p>
       <p>An exception to the above is if the exit reason is <c>kill</c>,
-        that is if <c>exit(Pid,kill)</c> has been called. This will
-        unconditionally terminate the process, regardless of if it is
-        trapping exit signals or not.</p>
+        that is if <c>exit(Pid,kill)</c> has been called. This
+        unconditionally terminates the process, regardless of if it is
+        trapping exit signals.</p>
     </section>
   </section>
 
@@ -180,12 +195,12 @@ process_flag(trap_exit, true)</pre>
     <p>If <c>Pid2</c> does not exist, the 'DOWN' message is sent
       immediately with <c>Reason</c> set to <c>noproc</c>.</p>
     <p>Monitors are unidirectional. Repeated calls to
-      <c>erlang:monitor(process, Pid)</c> will create several,
-      independent monitors and each one will send a 'DOWN' message when
+      <c>erlang:monitor(process, Pid)</c> creates several
+      independent monitors, and each one sends a 'DOWN' message when
       <c>Pid</c> terminates.</p>
     <p>A monitor can be removed by calling
       <c>erlang:demonitor(Ref)</c>.</p>
-    <p>It is possible to create monitors for processes with registered
+    <p>Monitors can be created for processes with registered
       names, also at other nodes.</p>
   </section>