Fix typos in Programming Examples

system/doc/programming_examples/bit_syntax.md

@@ -77,7 +77,7 @@ This gives two binaries of size 3, with the following evaluations:
 - [`binary_to_list(Bin11)`](`binary_to_list/1`) evaluates to `[1, 17, 42]`.
 - [`binary_to_list(Bin12)`](`binary_to_list/1`) evaluates to `[97, 98, 99]`.
 
-*Example 2:*Similarly, a binary can be constructed from a set of bound
+*Example 2:* Similarly, a binary can be constructed from a set of bound
 variables:
 
 ```erlang
@@ -86,7 +86,7 @@ Bin2 = <<A, B, C:16>>
 ```
 
 This gives a binary of size 4. Here, a _size expression_ is used for the
-variable `C` to specify a 16-bits segment of `Bin2`.
+variable `C` to specify a 16-bit segment of `Bin2`.
 
 [`binary_to_list(Bin2)`](`binary_to_list/1`) evaluates to `[1, 17, 00, 42]`.
 
@@ -135,7 +135,7 @@ variables do. Both can bind to empty binaries.
 
 The match of `Dgram` fails if one of the following occurs:
 
-- The first 4-bits segment of `Dgram` is not equal to 4.
+- The first 4-bit segment of `Dgram` is not equal to 4.
 - `HLen` is less than 5.
 - The size of `Dgram` is less than `4*HLen`.
 
@@ -150,7 +150,7 @@ Each segment has the following general syntax:
 
 `Value:Size/TypeSpecifierList`
 
-The `Size` or the `TypeSpecifier`, or both, can be omitted. Thus, the following
+The `Size` or the `TypeSpecifierList`, or both, can be omitted. Thus, the following
 variants are allowed:
 
 - `Value`
@@ -240,7 +240,7 @@ _Example:_
 ```
 
 The variable `Bin` must contain a whole number of bytes, because the `binary`
-type defaults to `unit:8`. A `badarg` exception is generated if `Bin` consist
+type defaults to `unit:8`. A `badarg` exception is generated if `Bin` consists
 of, for example, 17 bits.
 
 The `Bitstring` variable can consist of any number of bits, for example, 0, 1,
@@ -264,7 +264,7 @@ As mentioned earlier, segments have the following general syntax:
 
 When constructing binaries, `Value` and `Size` can be any Erlang expression.
 However, for syntactical reasons, both `Value` and `Size` must be enclosed in
-parenthesis if the expression consists of anything more than a single literal or
+parentheses if the expression consists of anything more than a single literal or
 a variable. The following gives a compiler syntax error:
 
 ```erlang
@@ -309,7 +309,7 @@ As mentioned earlier, segments have the following general syntax:
 
 `Value:Size/TypeSpecifierList`
 
-When matching `Value`, value must be either a variable or an integer, or a
+When matching `Value`, `Value` must be either a variable or an integer, or a
 floating point literal. Expressions are not allowed.
 
 `Size` must be a
@@ -349,7 +349,7 @@ bar(<<Sz:8,Payload:Sz/binary-unit:8,Rest/binary>>) ->
 ```
 
 Here `Sz` is bound to the value in the first byte of the binary. `Sz` is then
-used at the number of bytes to match out as a binary.
+used as the number of bytes to match out as a binary.
 
 Starting in OTP 23, the size can be a guard expression:
 

system/doc/programming_examples/funs.md

@@ -125,15 +125,15 @@ Using the function `foreach`, the function `broadcast` becomes:
 foreach(fun(Pid) -> Pid ! M end, L)
 ```
 
-`foreach` is evaluated for its side-effect and not its value. `foreach(Fun ,L)`
+`foreach` is evaluated for its side-effect and not its value. `foreach(Fun, L)`
 calls `Fun(X)` for each element `X` in `L` and the processing occurs in the
 order that the elements were defined in `L`. `map` does not define the order in
 which its elements are processed.
 
 ## Syntax of Funs
 
 Funs are written with the following syntax (see
-[Fun Expressions ](`e:system:expressions.md#fun-expressions`)for full description):
+[Fun Expressions](`e:system:expressions.md#fun-expressions`) for full description):
 
 ```erlang
 F = fun (Arg1, Arg2, ... ArgN) ->
@@ -249,7 +249,7 @@ diagnostic:
 This indicates that the variable `File`, which is defined inside the fun,
 collides with the variable `File`, which is defined outside the fun.
 
-The rules for importing variables into a fun has the consequence that certain
+The rules for importing variables into a fun have the consequence that certain
 pattern matching operations must be moved into guard expressions and cannot be
 written in the head of the fun. For example, you might write the following code
 if you intend the first clause of `F` to be evaluated when the value of its
@@ -323,7 +323,7 @@ any(Pred, []) ->
 A predicate is a function that returns `true` or `false`. `any` is `true` if
 there is a term `X` in the list such that `P(X)` is `true`.
 
-A predicate `Big(X)` is defined, which is `true` if its argument is greater that
+A predicate `Big(X)` is defined, which is `true` if its argument is greater than
 10:
 
 ```erlang
@@ -489,7 +489,7 @@ diff(L1, L2) ->
 
 This gives the list of all elements in L1 that are not contained in L2.
 
-The AND intersection of the list `L1` and `L2` is also easily defined:
+The AND intersection of the lists `L1` and `L2` is also easily defined:
 
 ```erlang
 intersection(L1,L2) -> filter(fun(X) -> member(X,L1) end, L2).
@@ -537,7 +537,7 @@ dropwhile(Pred, []) ->
 ### splitwith
 
 `lists:splitwith/2` splits the list `L` into the two sublists `{L1, L2}`, where
-`L = takewhile(P, L)` and `L2 = dropwhile(P, L)`:
+`L1 = takewhile(P, L)` and `L2 = dropwhile(P, L)`:
 
 ```erlang
 splitwith(Pred, L) ->
@@ -561,7 +561,7 @@ splitwith(Pred, [], L) ->
 
 So far, only functions that take funs as arguments have been described. More
 powerful functions, that themselves return funs, can also be written. The
-following examples illustrate these type of functions.
+following examples illustrate these types of functions.
 
 ### Simple Higher Order Functions
 
@@ -619,7 +619,7 @@ Parser(Toks) -> {ok, Tree, Toks1} | fail
 `{ok, Tree, Toks1}`.
 
 - `Tree` is a parse tree.
-- `Toks1` is a tail of `Tree` that contains symbols encountered after the
+- `Toks1` is a tail of `Toks` that contains symbols encountered after the
   structure that was correctly parsed.
 
 An unsuccessful parse returns `fail`.

system/doc/programming_examples/list_comprehensions.md

@@ -138,7 +138,7 @@ removed:
 Pythagorean triplets are sets of integers `{A,B,C}` such that
 `A**2 + B**2 = C**2`.
 
-The function `pyth(N)` generates a list of all integers `{A,B,C}` such that
+The function `pyth(N)` generates a list of all tuples `{A,B,C}` such that
 `A**2 + B**2 = C**2` and where the sum of the sides is equal to, or less than,
 `N`:
 
@@ -208,7 +208,7 @@ The scope rules for variables that occur in list comprehensions are as follows:
 - Any variables that are defined before the list comprehension, and that are
   used in filters, have the values they had before the list comprehension.
 - Variables cannot be exported from a list comprehension.
-- Within a zip generator, binding of all variables happen at the same time.
+- Within a zip generator, binding of all variables happens at the same time.
 
 As an example of these rules, suppose you want to write the function `select`,
 which selects certain elements from a list of tuples. Suppose you write
@@ -256,7 +256,7 @@ same name bound in a previous generator pattern. For example:
 [{a,a},{b,b},{c,c},{a,a},{b,b},{c,c},{a,a},{b,b},{c,c}]
 ```
 
-A consequence of the rules for importing variables into a list comprehensions is
+A consequence of the rules for importing variables into a list comprehension is
 that certain pattern matching operations must be moved into the filters and
 cannot be written directly in the generators.
 
@@ -305,7 +305,7 @@ linter. It extracts arities from all defined functions. All elements in the
 list `DefinedFuns` are two-tuples, containing name and arity for functions.
 If any of them differs from this pattern, it means that something has added
 an invalid item into the list of defined functions. It is better for the linter
-to crash in the comprehension than skipping the invalid item and continue
+to crash in the comprehension than to skip the invalid item and continue
 running. Using a strict generator here is correct, because the linter should
 not hide the presence of an internal inconsistency.
 
@@ -320,9 +320,9 @@ from the comprehension result.
 
 For example, the following comprehension is from a compiler module that
 transforms normal Erlang code to Core Erlang. It finds all defined functions
-from an abstract form, and output them in two-tuples, each containing name and
+from an abstract form, and outputs them in two-tuples, each containing name and
 arity of a function. Not all forms are function declarations. All the forms
-that are not function declarations should be ignored by this comprehensions.
+that are not function declarations should be ignored by this comprehension.
 Using a relaxed generator here is correct, because the programmer intends to
 exclude all elements with other patterns.
 

system/doc/programming_examples/prog_ex_records.md

@@ -57,8 +57,8 @@ following example, a record instead of a tuple is used to store the data:
 ```
 
 This enables references to the fields of the record by name. For example, if `P`
-is a variable whose value is a `person` record, the following code access the
-name and address fields of the records:
+is a variable whose value is a `person` record, the following code accesses the
+name and address fields of the record:
 
 ```erlang
 Name = P#person.name,
@@ -74,9 +74,9 @@ Internally, records are represented using tagged tuples:
 
 ## Defining a Record
 
-This following definition of a `person` is used in several examples in this
+The following definition of a `person` is used in several examples in this
 section. Three fields are included, `name`, `phone`, and `address`. The default
-values for `name` and `phone` is "" and [], respectively. The default value for
+values for `name` and `phone` are "" and [], respectively. The default value for
 `address` is the atom `undefined`, since no default value is supplied for this
 field:
 
@@ -145,7 +145,7 @@ The following example shows how to update a record:
 
 ## Type Testing
 
-The following example shows that the guard succeeds if `P` is record of type
+The following example shows that the guard succeeds if `P` is a record of type
 `person`:
 
 ```erlang