Fix typos in Design Principles

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

Author: juhlig

system/doc/design_principles/applications.md

@@ -32,7 +32,7 @@ After creating code to implement a specific functionality, you might
 consider transforming it into an *application* — a component that can be
 started and stopped as a unit, as well as reused in other systems.
 
-The steps to create an application is as follows:
+The steps to create an application are as follows:
 
 * Create an [application callback
   module](applications.md#callback_module) that describes how the
@@ -240,8 +240,8 @@ Other directories in the development environment may be needed. If source code
 from languages other than Erlang is used, for instance C-code for NIFs, that
 code should be placed in a separate directory. By convention it is recommended
 to prefix such directories with the language name, for example `c_src` for C,
-`java_src` for Java or `go_src` for Go. Directories with `_src` suffix indicates
-that it is a part of the application and the compilation step. The final build
+`java_src` for Java or `go_src` for Go. Directories with `_src` suffix indicate
+that they are a part of the application and the compilation step. The final build
 artifacts should target the `priv/lib` or `priv/bin` directories.
 
 The `priv` directory holds assets that the application needs during runtime.
@@ -309,7 +309,7 @@ A released application must follow a certain structure.
 
 The `src` directory could be useful to release for debugging purposes,
 but this is not required. The `include` directory should only be
-released if the applications has public include files.
+released if the application has public include files.
 
 It is encouraged to omit empty directories.
 
@@ -406,7 +406,7 @@ ok
 
 The application master stops the application by telling the top supervisor to
 shut down. The top supervisor tells all its child processes to shut down, and so
-on; the entire tree is terminated in reversed start order. The application
+on; the entire tree is terminated in reverse start order. The application
 master then calls the application callback function `stop/1` in the module
 defined by the `mod` key.
 

system/doc/design_principles/appup_cookbook.md

@@ -116,7 +116,7 @@ code_change(_Vsn, Chs, _Extra) ->
 ```
 
 The first argument is `{down,Vsn}` if there is a downgrade, or `Vsn` if there is
-a upgrade. The term `Vsn` is fetched from the 'original' version of the module,
+an upgrade. The term `Vsn` is fetched from the 'original' version of the module,
 that is, the version you are upgrading from, or downgrading to.
 
 The version is defined by the module attribute `vsn`, if any. There is no such
@@ -133,7 +133,7 @@ example in [Release Handling](release_handling.md#appup), where a function
 `available/0` is added to `ch3`.
 
 If a call is added to this function, say in module `m1`, a runtime error could
-can occur during release upgrade if the new version of `m1` is loaded first and
+occur during release upgrade if the new version of `m1` is loaded first and
 calls `ch3:available/0` before the new version of `ch3` is loaded.
 
 Thus, `ch3` must be loaded before `m1`, in the upgrade case, and conversely in
@@ -263,7 +263,7 @@ the restart strategy and maximum restart frequency properties, as well as
 changing the existing child specifications.
 
 Child processes can be added or deleted, but this is not handled automatically.
-Instructions must be given by in the `.appup` file.
+Instructions must be given in the `.appup` file.
 
 ### Changing Properties
 
@@ -396,6 +396,7 @@ A new functional module `m` is added to `ch_app`:
 {"2",
  [{"1", [{add_module, m}]}],
  [{"1", [{delete_module, m}]}]
+}.
 ```
 
 ## Starting or Terminating a Process
@@ -467,7 +468,7 @@ manually created.
 _Example_
 
 Assume there is a release containing an application `prim_app`, which
-have a supervisor `prim_sup` in its supervision tree.
+has a supervisor `prim_sup` in its supervision tree.
 
 In a new version of the release, the application `ch_app` is to be included in
 `prim_app`. That is, its topmost supervisor `ch_sup` is to be started as a child
@@ -572,7 +573,7 @@ processes to/from `prim_sup` with instructions for loading/unloading all
 Again, the `.relup` file is created manually, either from scratch or by editing a
 generated version. Load all code for `ch_app` first, and also load the
 application specification, before `prim_sup` is updated. When downgrading,
-`prim_sup` is to updated first, before the code for `ch_app` and its application
+`prim_sup` is to be updated first, before the code for `ch_app` and its application
 specification are unloaded.
 
 ```erlang

system/doc/design_principles/design_principles.md

@@ -38,7 +38,7 @@ structuring model based on the idea of _workers_ and _supervisors_:
   and workers, which makes it possible to design and program fault-tolerant
   software.
 
-In the following figure, square boxes represents supervisors and circles
+In the following figure, square boxes represent supervisors and circles
 represent workers:
 
 [](){: #sup6 }
@@ -74,7 +74,7 @@ The behaviour module is part of Erlang/OTP. To implement a process such as a
 supervisor, the user only needs to implement the callback module, which is to
 export a pre-defined set of functions, the _callback functions_.
 
-The following example illustrate how code can be divided into a generic and a
+The following example illustrates how code can be divided into a generic and a
 specific part. Consider the following code (written in plain Erlang) for a
 simple server, which keeps track of a number of "channels". Other processes can
 allocate and free the channels by calling the functions `alloc/0` and `free/1`,
@@ -289,7 +289,7 @@ How to program applications is described in [Applications](applications.md).
 
 ## Releases
 
-A _release_ is a complete system made out from a subset of Erlang/OTP
+A _release_ is a complete system made from a subset of Erlang/OTP
 applications and a set of user-specific applications.
 
 How to program releases is described in [Releases](release_structure.md).

system/doc/design_principles/distributed_applications.md

@@ -36,7 +36,7 @@ distributed in the sense that they, for example, use services on other nodes.
 
 Since a distributed application can move between nodes, some addressing
 mechanism is required to ensure that it can be addressed by other applications,
-regardless on which node it currently executes. This issue is not addressed
+regardless of which node it currently executes. This issue is not addressed
 here, but the `m:global` or `m:pg` modules in Kernel can be used for this purpose.
 
 ## Specifying Distributed Applications

system/doc/design_principles/gen_server_concepts.md

@@ -234,7 +234,7 @@ set in the supervisor.
 
 If it is necessary to clean up before termination, the shutdown strategy
 must be a time-out value and the `gen_server` must be set to trap exit signals
-in function `init`. When ordered to shutdown, the `gen_server` then calls
+in function `init`. When ordered to shut down, the `gen_server` then calls
 the callback function `terminate(shutdown, State)`:
 
 ```erlang
@@ -259,7 +259,7 @@ can be useful, for example:
 
 ```erlang
 ...
-export([stop/0]).
+-export([stop/0]).
 ...
 
 stop() ->

system/doc/design_principles/release_handling.md

@@ -49,13 +49,13 @@ of the Kernel, STDLIB, and SASL applications.
 _Step 1_) A release is created as described in [Releases](release_structure.md).
 
 _Step 2_) The release is transferred to and installed at target environment. For
-information of how to install the first target system, see
+information on how to install the first target system, see
 [System Principles](`e:system:create_target.md`).
 
 _Step 3_) Modifications, for example, error corrections, are made to the code in
 the development environment.
 
-_Step 4_) At some point, it is time to make a new version of release. The
+_Step 4_) At some point, it is time to make a new version of the release. The
 relevant `.app` files are updated and a new `.rel` file is written.
 
 _Step 5_) For each modified application, an
@@ -240,7 +240,7 @@ If a new module is introduced, the following instruction is used:
 ```
 
 This instruction loads module `Module`. When running Erlang in
-embedded mode it is necessary to use this this instruction. It is not
+embedded mode it is necessary to use this instruction. It is not
 strictly required when running Erlang in interactive mode, since the
 code server automatically searches for and loads unloaded modules.
 
@@ -695,7 +695,7 @@ function `ch3:available/0` is now available:
 ".../lib/ch_app-1/ebin/ch_sup.beam"
 ```
 
-Processes in `ch_app` for which code have not been updated, for example, the
+Processes in `ch_app` for which code has not been updated, for example, the
 supervisor, are still evaluating code from `ch_app-1`.
 
 _Step 8)_ If the target system is now rebooted, it uses version "A" again. The
@@ -735,7 +735,7 @@ When an installed release is made permanent, the system process `init` is set to
 point out the new `sys.config`.
 
 After the installation, the application controller compares the old and new
-configuration parameters for all running applications and call the callback
+configuration parameters for all running applications and calls the callback
 function:
 
 ```erlang

system/doc/design_principles/spec_proc.md

@@ -306,7 +306,7 @@ is to be called:
 sys:handle_debug(Deb, Func, Info, Event) => Deb1
 ```
 
-The arguments have the follow meaning:
+The arguments have the following meaning:
 
 - `Deb` is the debug structure as returned from `sys:debug_options/1`.
 - `Func` is a fun specifying a (user-defined) function used to format trace
@@ -373,10 +373,10 @@ The arguments have the following meaning:
 - `Request` and `From` from the received system message are to be
   passed as-is to the call to `sys:handle_system_msg/6`.
 - `Parent` is the pid of the parent process.
-- `Module` is the name of the module implementing the speciall process.
+- `Module` is the name of the module implementing the special process.
 - `Deb` is the debug structure.
 - `State` is a term describing the internal state and is passed on to
-  `Module:system_continue/3`, `Module:system_terminate/4`/
+  `Module:system_continue/3`, `Module:system_terminate/4`,
   `Module:system_get_state/1`, and `Module:system_replace_state/2`.
 
 `sys:handle_system_msg/6` does not return. It handles the system
@@ -394,7 +394,7 @@ one of the following functions:
 * `Module:system_get_state(State)` - if the process is to return its state.
 
 * `Module:system_replace_state(StateFun, State)` - if the process is
-  to replace its state using the fun `StateFun` fun. See `sys:replace_state/3`
+  to replace its state using the fun `StateFun`. See `sys:replace_state/3`
   for more information.
 
 * `system_code_change(Misc, Module, OldVsn, Extra)` - if the process is to
@@ -403,7 +403,7 @@ one of the following functions:
 A process in a supervision tree is expected to terminate with the same reason as
 its parent.
 
-In the example, system messages are handed by the following code:
+In the example, system messages are handled by the following code:
 
 ```erlang
 loop(Chs, Parent, Deb) ->
@@ -422,7 +422,7 @@ system_terminate(Reason, Parent, Deb, Chs) ->
     exit(Reason).
 
 system_get_state(Chs) ->
-    {ok, Chs, Chs}.
+    {ok, Chs}.
 
 system_replace_state(StateFun, Chs) ->
     NChs = StateFun(Chs),
@@ -543,7 +543,7 @@ init(Parent, Name, Module) ->
     ...,
     Dbg = sys:debug_options([]),
     proc_lib:init_ack(Parent, {ok, self()}),
-    loop(Parent, Module, Deb, ...).
+    loop(Parent, Module, Dbg, ...).
 
 ...
 ```

system/doc/design_principles/statem.md

@@ -243,7 +243,7 @@ to the [`handle_event()`](`c:gen_statem:handle_event/4`) callback.  The
 other arguments are the `EventType` and the event dependent `EventContent`,
 both described in section
 [_Event Types and Event Content_](#event-types-and-event-content),
-and the the last argument is the current server `Data`.
+and the last argument is the current server `Data`.
 
 [_State Enter Calls_](#state-enter-calls) (see that section)
 are also handled by the event handler and have slightly different arguments.
@@ -323,7 +323,7 @@ _transition actions_:
   If `true` postpone the current event, see section
   [_Postponing Events_](#postponing-events).
 
-- **[`{hibernate, Boolean`](`t:gen_statem:hibernate/0`)** -
+- **[`{hibernate, Boolean}`](`t:gen_statem:hibernate/0`)** -
   If `true` hibernate the `gen_statem`, treated in section
   [_Hibernation_](#hibernation).
 
@@ -512,7 +512,7 @@ the time-out is restarted with the new time and event content.
 
 All time-outs have an `EventContent` that is part of the
 [_transition action_](#transition-actions) that starts the time-out.
-Different `EventContent`s does not create different time-outs. The
+Different `EventContent`s do not create different time-outs. The
 `EventContent` is delivered to the [_state callback_](#state-callback)
 when the time-out expires.
 
@@ -689,7 +689,7 @@ function `code_lock:init(Code)`. This function is expected to return
 in this case `locked`; assuming that the door is locked to begin with.
 `Data` is the internal server data of the `gen_statem`. Here the server data
 is a [`map()`](`m:maps`) with key `code` that stores the correct
-button sequence, key `length` store its length, and key `buttons`
+button sequence, key `length` stores its length, and key `buttons`
 that stores the collected buttons up to the same length.
 
 ```erlang
@@ -705,7 +705,7 @@ and is ready to receive events.
 
 Function [`gen_statem:start_link/3,4`](`gen_statem:start_link/3`)
 must be used if the `gen_statem` is part of a supervision tree, that is,
-started by a supervisor.  Function,
+started by a supervisor.  Function
 [`gen_statem:start/3,4`](`gen_statem:start/3`) can be used to start
 a standalone `gen_statem`, meaning it is not part of a supervision tree.
 
@@ -785,7 +785,7 @@ State Time-Outs
 ---------------
 
 When a correct code has been given, the door is unlocked and the following
-tuple is returned from `locked/2`:
+tuple is returned from `locked/3`:
 
 ```erlang
 {next_state, open, Data#{buttons := []},
@@ -1035,7 +1035,7 @@ the _event time-out_.
 Generic Time-Outs
 -----------------
 
-The previous example of _state time-outs_ only work if the state machine stays
+The previous example of _state time-outs_ only works if the state machine stays
 in the same state during the time-out time. And _event time-outs_ only work
 if no disturbing unrelated events occur.
 
@@ -1150,7 +1150,7 @@ Postponing is ordered by the
 [_transition action_](#transition-actions) `postpone`.
 
 In this example, instead of ignoring button events while in the `open` state,
-we can postpone them handle them later in the `locked` state:
+we can postpone them and handle them later in the `locked` state:
 
 ```erlang
 ...
@@ -1284,7 +1284,7 @@ just need to handle these event-like calls in all states.
 ...
 init(Code) ->
     process_flag(trap_exit, true),
-    Data = #{code => Code, length = length(Code)},
+    Data = #{code => Code, length => length(Code)},
     {ok, locked, Data}.
 
 callback_mode() ->
@@ -1327,7 +1327,7 @@ state machine.  This can be done with the
 [`{next_event, EventType, EventContent}`](`t:gen_statem:action/0`).
 
 You can generate events of any existing [type](`t:gen_statem:action/0`),
-but the`internal` type can only be generated through action `next_event`.
+but the `internal` type can only be generated through action `next_event`.
 Hence, it cannot come from an external source, so you can be certain
 that an `internal` event is an event from your state machine to itself.
 

system/doc/design_principles/sup_princ.md

@@ -513,7 +513,7 @@ child_spec() = #{id => child_id(),             % mandatory
   `M` comes from the child's start `{M,F,A}`.
 
 _Example:_ The child specification to start the server `ch3` in the previous
-example look as follows:
+example looks as follows:
 
 ```erlang
 #{id => ch3,