Fix typos in Getting Started

Co-authored-by: Maria Scott <maria-12648430@hnc-agency.org>

Author: juhlig

system/doc/getting_started/conc_prog.md

@@ -71,7 +71,7 @@ done
 ```
 
 As shown, the function `say_something` writes its first argument the number of
-times specified by second argument. The function `start` starts two Erlang
+times specified by the second argument. The function `start` starts two Erlang
 processes, one that writes "hello" three times and one that writes "goodbye"
 three times. Both processes use the function `say_something`. Notice that a
 function used in this way by `spawn`, to start a process, must be exported from
@@ -149,7 +149,7 @@ start() ->
 ```erlang
 1> c(tut15).
 {ok,tut15}
-2> tut15: start().
+2> tut15:start().
 <0.36.0>
 Pong received ping
 Ping received pong
@@ -205,7 +205,7 @@ receive
    pattern2 ->
        actions2;
    ....
-   patternN
+   patternN ->
        actionsN
 end.
 ```
@@ -254,7 +254,7 @@ process "ping":
 Ping_PID ! pong
 ```
 
-Notice how the operator "\!" is used to send messages. The syntax of "\!" is:
+Notice how the operator `!` is used to send messages. The syntax of `!` is:
 
 ```erlang
 Pid ! Message
@@ -283,7 +283,7 @@ Pong_PID ! {ping, self()},
 ```
 
 `self/0` returns the pid of the process that executes `self/0`, in this case the
-pid of "ping". (Recall the code for "pong", this lands up in the variable
+pid of "ping". (Recall the code for "pong", this ends up in the variable
 `Ping_PID` in the `receive` previously explained.)
 
 "Ping" now waits for a reply from "pong":
@@ -397,7 +397,7 @@ pong ! {ping, self()},
 ## Distributed Programming
 
 Let us rewrite the ping pong program with "ping" and "pong" on different
-computers. First a few things are needed to set up to get this to work. The
+computers. First a few things need to be set up to get this to work. The
 distributed Erlang implementation provides a very basic authentication mechanism
 to prevent unintentional access to an Erlang system on another computer. Erlang
 systems which talk to each other must have the same _magic cookie_. The easiest
@@ -438,7 +438,7 @@ Erlang system running on a computer is called an _Erlang node_.
 
 (Note: `erl -sname` assumes that all nodes are in the same IP domain and we can
 use only the first component of the IP address, if we want to use nodes in
-different domains we use `-name` instead, but then all IP address must be given
+different domains we use `-name` instead, but then all IP addresses must be given
 in full.)
 
 Here is the ping pong example modified to run on two separate nodes:
@@ -483,20 +483,20 @@ started on kosken, called ping, and then a node on gollum, called pong.
 On kosken (on a Linux/UNIX system):
 
 ```text
-kosken> erl -sname ping
-Erlang (BEAM) emulator version 5.2.3.7 [hipe] [threads:0]
+kosken$ erl -sname ping
+Erlang/OTP 28 [erts-16.3] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]
 
-Eshell V5.2.3.7  (abort with ^G)
+Eshell V16.3 (press Ctrl+G to abort, type help(). for help)
 (ping@kosken)1>
 ```
 
 On gollum:
 
 ```text
-gollum> erl -sname pong
-Erlang (BEAM) emulator version 5.2.3.7 [hipe] [threads:0]
+gollum$ erl -sname pong
+Erlang/OTP 28 [erts-16.3] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]
 
-Eshell V5.2.3.7  (abort with ^G)
+Eshell V16.3 (press Ctrl+G to abort, type help(). for help)
 (pong@gollum)1>
 ```
 
@@ -533,7 +533,7 @@ Pong finished
 
 Looking at the `tut17` code, you see that the `pong` function itself is
 unchanged, the following lines work in the same way irrespective of on which
-node the "ping" process is executes:
+node the "ping" process is executed:
 
 ```erlang
 {ping, Ping_PID} ->
@@ -623,7 +623,7 @@ Before starting, notice the following:
 - This example only shows the message passing logic - no attempt has been made
   to provide a nice graphical user interface, although this can also be done in
   Erlang.
-- This sort of problem can be solved easier by use of the facilities in OTP,
+- This sort of problem can be solved more easily by using the facilities in OTP,
   which also provide methods for updating code on the fly and so on (see
   [OTP Design Principles](`e:system:design_principles.md`)).
 - The first program contains some inadequacies regarding handling of nodes which
@@ -666,9 +666,6 @@ File `messenger.erl`:
 %%% Reply {messenger, logged_on} logon was successful
 %%%
 %%% To server: {ClientPid, logoff}
-%%% Reply: {messenger, logged_off}
-%%%
-%%% To server: {ClientPid, logoff}
 %%% Reply: no reply
 %%%
 %%% To server: {ClientPid, message_to, ToName, Message} send a message
@@ -697,7 +694,7 @@ server_node() ->
     messenger@super.
 
 %%% This is the server process for the "messenger"
-%%% the user list has the format [{ClientPid1, Name1},{ClientPid22, Name2},...]
+%%% the user list has the format [{ClientPid1, Name1},{ClientPid2, Name2},...]
 server(User_List) ->
     receive
         {From, logon, Name} ->
@@ -734,22 +731,22 @@ server_logoff(From, User_List) ->
     lists:keydelete(From, 1, User_List).
 
 
-%%% Server transfers a message between user
+%%% Server transfers a message between users
 server_transfer(From, To, Message, User_List) ->
     %% check that the user is logged on and who he is
-    case lists:keysearch(From, 1, User_List) of
+    case lists:keyfind(From, 1, User_List) of
         false ->
             From ! {messenger, stop, you_are_not_logged_on};
-        {value, {From, Name}} ->
+        {From, Name} ->
             server_transfer(From, Name, To, Message, User_List)
     end.
 %%% If the user exists, send the message
 server_transfer(From, Name, To, Message, User_List) ->
     %% Find the receiver and send the message
-    case lists:keysearch(To, 2, User_List) of
+    case lists:keyfind(To, 2, User_List) of
         false ->
             From ! {messenger, receiver_not_found};
-        {value, {ToPid, To}} ->
+        {ToPid, To} ->
             ToPid ! {message_from, Name, Message},
             From ! {messenger, sent}
     end.
@@ -894,7 +891,7 @@ call. This would result in the process getting bigger and bigger for every loop.
 
 Functions in the `lists` module are used. This is a very useful module and a
 study of the manual page is recommended (`erl -man lists`).
-`lists:keymember(Key,Position,Lists)` looks through a list of tuples and looks
+`lists:keymember(Key,Position,List)` looks through a list of tuples and looks
 at `Position` in each tuple to see if it is the same as `Key`. The first element
 is position 1. If it finds a tuple where the element at `Position` is the same
 as `Key`, it returns `true`, otherwise `false`.
@@ -914,8 +911,8 @@ any) and returns the remaining list:
 [{x,y,z},{b,b,b},{q,r,s}]
 ```
 
-`lists:keysearch` is like `lists:keymember`, but it returns
-`{value,Tuple_Found}` or the atom `false`.
+`lists:keyfind` is like `lists:keymember`, but it returns
+`Tuple_Found` or the atom `false`.
 
 There are many very useful functions in the `lists` module.
 
@@ -974,19 +971,19 @@ server_transfer(From, fred, "hello", User_List),
 This checks that the pid `From` is in the `User_List`:
 
 ```erlang
-lists:keysearch(From, 1, User_List)
+lists:keyfind(From, 1, User_List)
 ```
 
-If `keysearch` returns the atom `false`, some error has occurred and the server
+If `keyfind` returns the atom `false`, some error has occurred and the server
 sends back the message:
 
 ```erlang
 From ! {messenger, stop, you_are_not_logged_on}
 ```
 
 This is received by the client, which in turn does [`exit(normal)`](`exit/1`)
-and terminates. If `keysearch` returns `{value,{From,Name}}` it is certain that
-the user is logged on and that his name (peter) is in variable `Name`.
+and terminates. If `keyfind` returns `{From,Name}` it is certain that
+the user is logged on and that their name (peter) is in the variable `Name`.
 
 Let us now call:
 
@@ -995,11 +992,11 @@ server_transfer(From, peter, fred, "hello", User_List)
 ```
 
 Notice that as this is `server_transfer/5`, it is not the same as the previous
-function `server_transfer/4`. Another `keysearch` is done on `User_List` to find
+function `server_transfer/4`. Another `keyfind` is done on `User_List` to find
 the pid of the client corresponding to fred:
 
 ```erlang
-lists:keysearch(fred, 2, User_List)
+lists:keyfind(fred, 2, User_List)
 ```
 
 This time argument 2 is used, which is the second element in the tuple. If this
@@ -1012,10 +1009,10 @@ From ! {messenger, receiver_not_found};
 
 This is received by the client.
 
-If `keysearch` returns:
+If `keyfind` returns:
 
 ```erlang
-{value, {ToPid, fred}}
+{ToPid, fred}
 ```
 
 The following message is sent to fred's client:

system/doc/getting_started/records_macros.md

@@ -59,7 +59,7 @@ introduced:
 %%% Configure the location of the server node,
 -define(server_node, messenger@super).
 
-%%%----END FILE----
+%%%----END FILE-----
 ```
 
 ```erlang
@@ -89,7 +89,7 @@ introduced:
 -record(message_to,{to_name, message}).
 %%% logoff
 
-%%%----END FILE----
+%%%----END FILE-----
 ```
 
 ```erlang
@@ -135,7 +135,7 @@ message(ToName, Message) ->
              ok
 end.
 
-%%%----END FILE----
+%%%----END FILE-----
 ```
 
 ```erlang
@@ -178,7 +178,7 @@ await_result() ->
             exit(timeout)
     end.
 
-%%%----END FILE---
+%%%----END FILE----
 ```
 
 ```erlang
@@ -194,7 +194,7 @@ server() ->
     process_flag(trap_exit, true),
     server([]).
 
-%%% the user list has the format [{ClientPid1, Name1},{ClientPid22, Name2},...]
+%%% the user list has the format [{ClientPid1, Name1},{ClientPid2, Name2},...]
 server(User_List) ->
     io:format("User list = ~p~n", [User_List]),
     receive
@@ -230,27 +230,27 @@ server_logon(From, Name, User_List) ->
 server_logoff(From, User_List) ->
     lists:keydelete(From, 1, User_List).
 
-%%% Server transfers a message between user
+%%% Server transfers a message between users
 server_transfer(From, To, Message, User_List) ->
     %% check that the user is logged on and who he is
-    case lists:keysearch(From, 1, User_List) of
+    case lists:keyfind(From, 1, User_List) of
         false ->
             From ! #abort_client{message=you_are_not_logged_on};
-        {value, {_, Name}} ->
+        {_, Name} ->
             server_transfer(From, Name, To, Message, User_List)
     end.
 %%% If the user exists, send the message
 server_transfer(From, Name, To, Message, User_List) ->
     %% Find the receiver and send the message
-    case lists:keysearch(To, 2, User_List) of
+    case lists:keyfind(To, 2, User_List) of
         false ->
             From ! #server_reply{message=receiver_not_found};
-        {value, {ToPid, To}} ->
+        {ToPid, To} ->
             ToPid ! #message_from{from_name=Name, message=Message},
             From !  #server_reply{message=sent}
     end.
 
-%%%----END FILE---
+%%%----END FILE----
 ```
 
 ## Header Files
@@ -269,7 +269,7 @@ for example:
 ```
 
 In the case above the file is fetched from the same directory as all the other
-files in the messenger example. (_manual_).
+files in the messenger example. (_manual_)
 
 .hrl files can contain any valid Erlang code but are most often used for record
 and macro definitions.
@@ -297,7 +297,7 @@ This is equivalent to:
 Creating a record is best illustrated by an example:
 
 ```erlang
-#message_to{message="hello", to_name=fred)
+#message_to{message="hello", to_name=fred}
 ```
 
 This creates:
@@ -306,8 +306,8 @@ This creates:
 {message_to, fred, "hello"}
 ```
 
-Notice that you do not have to worry about the order you assign values to the
-various parts of the records when you create it. The advantage of using records
+Notice that you do not have to worry about the order in which you assign values to the
+various parts of a record when you create it. The advantage of using records
 is that by placing their definitions in header files you can conveniently define
 interfaces that are easy to change. For example, if you want to add a new field
 to the record, you only have to change the code where the new field is used and
@@ -358,7 +358,7 @@ This is a standard macro (that is, defined by the system, not by the user).
 of using macros with, for example, [parameters](macros.md#defining-and-using-macros).
 
 The three Erlang (`.erl`) files in the messenger example are individually
-compiled into object code file (`.beam`). The Erlang system loads and links
+compiled into object code files (`.beam`). The Erlang system loads and links
 these files into the system when they are referred to during execution of the
 code. In this case, they are simply put in our current working directory (that
 is, the place you have done "cd" to). There are ways of putting the `.beam`