Minor text fixes from a recent read-through

book/concurrent-programming/README.md

@@ -841,12 +841,14 @@ library/DuckDuckGo searching example]{.idx}
   HTTP URLs are an example.
 
 `yojson`
-: A JSON parsing library that was described in
+: A JSON parsing library that is described in
   [Handling Json Data](json.html#handling-json-data){data-type=xref}.
 
 `cohttp`
-: A library for creating HTTP clients and servers. We need Async support,
-  which comes with the `cohttp-async` package.
+: A library for creating HTTP clients and servers. 
+
+`cohttp-async`
+: A package providing Async support for `cohttp`.
 
 Now let's dive into the implementation.
 
@@ -884,7 +886,7 @@ of encoding the URI correctly when outputting it in the network protocol.
 The HTTP response from DuckDuckGo is in JSON, a common (and thankfully
 simple) format that is specified in
 [RFC4627](http://www.ietf.org/rfc/rfc4627.txt). We'll parse the JSON data
-using the Yojson library, which was introduced in
+using the Yojson library, which is introduced in
 [Handling Json Data](json.html#handling-json-data){data-type=xref}.
 [Yojson library/parsing JSON with]{.idx}[DuckDuckGo search engine/parsing
 JSON strings in]{.idx}[RFC4627]{.idx}

book/data-serialization/README.md

@@ -805,8 +805,8 @@ And here's the resulting lighter syntax.
 
 ### `@sexp.option` {#sexp_option}
 
-By default, optional values are represented either as `()` for
-`None`. Here's an example of a record type containing an option:
+By default, optional values are represented as `()` for `None`.
+Here's an example of a record type containing an option:
 [ppx_sexp_conv/sexp.option]{.idx}
 
 ```ocaml env=main

book/error-handling/README.md

@@ -648,10 +648,10 @@ file-descriptor leak.
 We can fix this using Base's `Exn.protect` function, which takes two
 arguments: a thunk `f`, which is the main body of the computation to be run;
 and a thunk `finally`, which is to be called when `f` exits, whether it exits
-normally or with an exception. This is similar to the `try/finally` construct
-available in many programming languages, but it is implemented in a library,
-rather than being a built-in primitive. Here's how it could be used to fix
-our `load` function:
+normally or with an exception. (A thunk is a function whose argument is of
+type unit.) This is similar to the `try/finally` construct available in many
+programming languages, but it is implemented in a library, rather than being
+a built-in primitive. Here's how it could be used to fix our `load` function:
 
 ```ocaml env=main
 # let load filename =

book/garbage-collector/README.md

@@ -597,11 +597,13 @@ collection/finalizer functions]{.idx}
 #### What Values Can Be Finalized?
 
 Various values cannot have finalizers attached since they aren't
-heap-allocated. Some examples of values that are not heap-allocated are
-integers, constant constructors, Booleans, the empty array, the empty list,
-and the unit value. The exact list of what is heap-allocated or not is
-implementation-dependent, which is why Core provides the `Heap_block` module
-to explicitly check before attaching the finalizer.
+heap-allocated. Core provides a `Heap_block` module that dynamically checks
+if a given value is suitable for finalizing.  Some examples of values that
+are not heap-allocated are integers, constant constructors, Booleans, the
+empty array, the empty list, and the unit value. The exact list of what is
+heap-allocated or not is implementation-dependent, which is why Core
+provides the `Heap_block` module to explicitly check before attaching the
+finalizer.
 
 Some constant values can be heap-allocated but never deallocated during the
 lifetime of the program, for example, a list of integer constants.
@@ -612,8 +614,8 @@ These may be finalized while another duplicate copy is being used by the
 program.
 :::
 
-Core provides a `Heap_block` module that dynamically checks if a given
-value is suitable for finalizing.  Core keeps the functions for
+
+Core keeps the functions for
 registering finalizers in the `Core.Gc.Expert` module. Finalizers
 can run at any time in any thread, so they can be pretty hard to reason
 about in multi-threaded contexts. [heaps/Heap_block module]{.idx}
@@ -667,7 +669,7 @@ $ dune exec -- ./finalizer.exe
 The GC calls the finalization functions in the order of the deallocation. If
 several values become unreachable during the same GC cycle, the finalization
 functions will be called in the reverse order of the corresponding calls to
-`add_finalizer`. Each call to `add_finalizer` adds to the set of functions,
+`add_finalizer`. Each call to `add_finalizer` adds to the set of functions
 which are run when the value becomes unreachable. You can have many
 finalizers all pointing to the same heap block if you wish.
 

book/json/README.md

@@ -196,7 +196,7 @@ OK
 The `from_file` function accepts an input filename and takes care of opening
 and closing it for you. It's far more common to use `from_string` to
 construct JSON values though, since these strings come in via a network
-connection (we'll see more of this in
+connection (we see more of this in
 [Concurrent Programming With Async](concurrent-programming.html#concurrent-programming-with-async){data-type=xref})
 or a database. Finally, the example checks that the two input mechanisms
 actually resulted in the same OCaml data structure.
@@ -340,7 +340,7 @@ val pages : int = 450
 The `tags` field is similar to `title`, but the field is a list of strings
 instead of a single one. Converting this to an OCaml `string list` is a
 two-stage process. First, we convert the JSON `List` to an OCaml list of JSON
-values and then filter out the `String` values as an OCaml `string list`.
+values and then filter out the `String` values into an OCaml `string list`.
 Remember that OCaml lists must contain values of the same type, so any JSON
 values that cannot be converted to a `string` will be skipped from the output
 of `filter_string`:

book/runtime-memory-layout/README.md

@@ -403,6 +403,12 @@ parameters: a block with the current value, and a pointer to the rest of the
 list. [debugging/Obj module warning]{.idx}[security issues/Obj module
 warning]{.idx}[Obj module]{.idx}
 
+Due to this encoding, there is a limit around 240 variants with parameters
+that applies to each type definition, but the only limit on the number of
+variants without parameters is the size of the native integer (either 31 or
+63 bits). This limit arises because of the size of the tag byte, and that
+some of the high-numbered tags are reserved.
+
 ::: {data-type=warning}
 ##### Obj Module Considered Harmful
 
@@ -418,13 +424,6 @@ machine proof of correctness to accompany your use of `Obj`, stay away from
 it except for debugging!
 :::
 
-
-Due to this encoding, there is a limit around 240 variants with parameters
-that applies to each type definition, but the only limit on the number of
-variants without parameters is the size of the native integer (either 31 or
-63 bits). This limit arises because of the size of the tag byte, and that
-some of the high-numbered tags are reserved.
-
 ## Polymorphic Variants {#polymorphic-variants-1}
 
 Polymorphic variants are more flexible than normal variants when writing code

book/testing/README.md

@@ -208,8 +208,8 @@ libraries has several downsides.
   of the public API often does a better job of testing what's
   fundamental about your code, and will better survive refactoring of
   the implementation.  Also, the discipline of keeping tests outside
-  of requires you to write code that can be tested that way, which
-  pushes towards better designs.
+  of your libraries requires you to write code that can be tested that
+  way, which pushes towards better designs.
 
 For all of these reasons, our recommendation is to put the bulk of
 your tests in test-only libraries created for that purpose.  There are