Merge pull request #288 from alex-sparus/fix-typos

Small fixes for the persist documentation

Author: arximboldi

doc/persist-introduction.rst

@@ -2,14 +2,14 @@ Introduction
 ===============
 
 The ``immer::persist`` library persists persistent data structures,
-allowing the preservation structural sharing of ``immer`` containers
+allowing the preservation of structural sharing of ``immer`` containers
 when serializing, deserializing or transforming the data.
 
 
-.. warning:: This library is still experimental and it's API may
+.. warning:: This library is still experimental and its API may
    change in the future. The headers can be found in
    ``immer/extra/persist/...`` and the ``extra`` subpath will be
-   removed once it's interface stabilises.
+   removed once its interface stabilizes.
 
 Dependencies
 ------------
@@ -30,7 +30,7 @@ runtime, two distinct containers can be operated on independently but
 internally they share nodes and use memory efficiently in that
 way.
 
-However when such containers are serialized in a trival form, for
+However when such containers are serialized in a trivial form, for
 example, as JSON lists, this sharing is lost: they become truly
 independent---the same data is stored multiple times on disk, and
 later, when read back into memory, the program has lost the structural
@@ -50,8 +50,8 @@ Consider this scenario where you have multiple
 ``immer::vector<std::string>``, where the various instances are
 derived from one another. Some of these vectors would be completely
 identical, while others would have just a few elements different. This
-scenario is not uncommon, for example, when `implement the undo
-history of an application by preseriving the previous
+scenario is not uncommon, for example, when `implementing the undo
+history of an application by preserving the previous
 states <https://sinusoid.es/lager/modularity.html#genericity>`_.
 
 The goal is to apply a transformation function to these vectors with
@@ -81,9 +81,9 @@ type. For example, we may have a pool that contains all
 ``immer::vector<int>`` of our document. You can think of it as a small
 database of ``immer`` containers. When serializing the pool, the
 internal structure of all those ``immer`` containers is written as
-whole, preserving the structural sharing between those containers.
+a whole, preserving the structural sharing between those containers.
 
 Note that for the most part, the user of the library is not concerned
 with pools, as they are generated automatically from your
-data-structures.  However, you may become aware of them in the JSON
+data structures.  However, you may become aware of them in the JSON
 output or when transforming recursive data structures.

doc/persist-serialization.rst

@@ -1,7 +1,7 @@
 Serialization
 =========
 
-Serializing your data structures using ``immer::persist`` allows you
+Serializing your data structures using ``immer::persist`` allows you to
 preserve the *structural sharing* across sessions of your application.
 
 This has multiple practical use cases, like storing the undo history
@@ -82,28 +82,28 @@ replaced by an identifier.  This identifier is a key into a
 :ref:`pool<pools>`, which is serialized just after.
 
 .. note::
-   Currently, ``immer-persist`` makes a distiction between
+   Currently, ``immer-persist`` makes a distinction between
    pools used for saving containers (*output* pools) and for loading
    containers (*input* pools), similar to ``cereal`` with its
-   ``InputArchive`` and ``OutputArchive`` distiction.
+   ``InputArchive`` and ``OutputArchive`` distinction.
 
 Currently, ``immer-persist`` focuses on JSON as the serialization
 format and uses the ``cereal`` library internally. In principle, other
 formats and serialization libraries could be supported in the future.
 sharing across sessions.
 
-You can see in the out that the nodes of the trees that make up the
+You can see in the output that the nodes of the trees that make up the
 ``immer`` containers are directly represented in the JSON and, because
-we are representing all the containers as a whole, those nodes that
-are referenced in multiple trees can be stored only once. That same
+we are representing all the containers as a whole, those nodes that are
+referenced in multiple trees can be stored only once. That same
 structure is preserved when reading the pool back from disk and
-reconstructing the vectors (and other containers) from it, thus
-allowing us to preserve the structural sharing across sessions.
+reconstructing the vectors (and other containers) from it, thus allowing
+us to preserve the structural sharing across sessions.
 
 Custom policies
 ----------
 
-We can use policy to control the names of the pools for each container.
+We can use policy to control the naming of the pools for each container.
 
 For this example, let's define a new document type ``doc_2``. It will
 also contain another type ``extra_data`` with a ``vector`` of