Merge branch 'bjorn/system-documentation'

* bjorn/system-documentation:
  Replace "lambda head" with "fun" in compiler warning
  Remove an historical note about fun representation before R6B
  Replace mention of a tuple fun with an external fun
  Update Interoperability Tutorial
  Update System Principles
  Update Erlang Reference Manual
  Update Getting Started
  Update Programming Examples
  Update OAM Principles
  Update Installation Guide
  Update Embedded Systems User's Guide
  Update Efficiency Guide
  Update Design Principles

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>