Fix grammatical and punctuation errors in the documentation. (#228)

docs/enduser_docs.rst

@@ -5,7 +5,7 @@
 End-user quickstart
 ===================
 
-Ideally, the only thing an end-user should have to do is set the backend and
+Ideally, the only thing an end-user should have to do is set the backend
 and its options. Given a backend, you (as the end-user) can decide to
 do one of two things:
 
@@ -15,7 +15,7 @@ do one of two things:
 .. note::
     API authors may want to wrap these methods and provide their own methods.
 
-Also of note may be the :obj:`BackendNotImplementedError`, which is raised
+Also of a note may be the :obj:`BackendNotImplementedError`, which is raised
 when none of the selected backends have an implementation for a multimethod.
 
 Setting the backend temporarily

docs/generated/uarray.rst

@@ -62,7 +62,7 @@ the core backend and dispatch machinery, and :obj:`unumpy` holds the actual
 multimethods. Also, :obj:`unumpy` can be developed completely separately to
 :obj:`uarray`, although the ideal place to have it would be NumPy itself.
 
-However, the benefit to having it separate is that it could span multiple
+However, the benefit of having it separate is that it could span multiple
 NumPy versions, even before NEP-18 (or even NEP-13) was available. Another
 benefit is that it can have a faster release cycle to help it achieve this.
 
@@ -82,7 +82,7 @@ Extensibility *and* Choice
 If some effort is put into the dispatch machinery, it's possible to
 dispatch over arbitrary objects --- including arrays, dtypes, and
 so on. A method defines the type of each dispatchable argument, and
-backends are *only* passed types they know how to dispatch over, when
+backends are *only* passed types they know how to dispatch over when
 deciding whether or not to use that backend. For example, if a backend
 doesn't know how to dispatch over dtypes, it won't be asked to decide
 based on that front.
@@ -138,15 +138,15 @@ Addressing past flaws
 
 The progress on NumPy's side for defining an override mechanism has been slow, with
 NEP-13 being first introduced in 2013, and with the wealth of dispatchable objects
-(including arrays, ufuns and dtypes), and with the advent of libraries like Dask,
-CuPy, Xarray, PyData/Sparse and XND, it has become clear that the need for alternative
+(including arrays, ufuns, and dtypes), and with the advent of libraries like Dask,
+CuPy, Xarray, PyData/Sparse, and XND, it has become clear that the need for alternative
 array-like implementations is growing. There are even other libraries like PyTorch, and
 TensorFlow that'd be possible to express in NumPy API-like terms. Another example
 includes the Keras API, for which an overridable ``ukeras`` could be created, similar
 to :obj:`unumpy`.
 
 :obj:`uarray` is intended to have fast development to fill the need posed by these
 communities, while keeping itself as general as possible, and quickly reach maturity,
-after which backwards compatibility will be guaranteed.
+after which backward compatibility will be guaranteed.
 
 Performance considerations will come only after such a state has been reached.

docs/glossary.rst

@@ -26,13 +26,13 @@ Domain
 ------
 
 A domain is a collection or grouping of multimethods. A domain's string,
-by convention (although not by force) is the name of the module that provides
+by convention (although not by force), is the name of the module that provides
 the multimethods.
 
 Dispatching
 -----------
 
-Dispatching is the process of forward a function call to an implementation
+Dispatching is the process of forwarding a function call to an implementation
 in a backend.
 
 Conversion

docs/index.rst

@@ -11,7 +11,7 @@
 
 .. note::
     This page describes the overall philosophy behind :obj:`uarray`. For usage instructions,
-    see the :obj:`uarray` API documentation page. If you are interested in an augmentation
+    see the :obj:`uarray` API documentation page. If you are interested in augmentation
     for NEP-22, please see the :obj:`unumpy` page.
 
 `uarray` is a backend system for Python that allows you to separately define an API,
@@ -29,10 +29,10 @@ library independent.
 
 :obj:`unumpy` is the first approach to leverage :obj:`uarray` in order to build a
 generic backend system for (what we hope will be) the core NumPy API. It will be
-possible to create a backend object, and use that to perform operations. In addition,
+possible to create a backend object and use that to perform operations. In addition,
 it will be possible to change the used backend via a context manager.
 
-Benefits for end users
+Benefits for end-users
 ----------------------
 
 End-users can easily take their code written for one backend and use it on another

docs/libauthor_docs.rst

@@ -19,7 +19,7 @@ the last is optional.
 
 ``__ua_domain__`` is a string containing the domain of the backend. This is,
 by convention, the name of the module (or one of its dependencies or parents)
-that contain the multimethods. For example, ``scipy`` and ``numpy.fft`` could
+that contains the multimethods. For example, ``scipy`` and ``numpy.fft`` could
 both use the ``numpy`` domain.
 
 ``__ua_function__``
@@ -41,7 +41,7 @@ operation.
 
 All dispatchable arguments are passed through ``__ua_convert__`` before being
 passed into ``__ua_function__``. This protocol has the signature
-``(dispatchables, coerce)``, where ``dispatchables`` is an iterable of
+``(dispatchables, coerce)``, where ``dispatchables`` is iterable of
 :obj:`Dispatchable` and ``coerce`` is whether or not to coerce forcefully.
 ``dispatch_type`` is the mark of the object to be converted, and ``coerce``
 specifies whether or not to "force" the conversion. By convention, operations
@@ -53,13 +53,13 @@ coerced, then one should return ``NotImplemented``.
 A convenience wrapper for converting a single object,
 :obj:`wrap_single_convertor` is provided.
 
-Returning :obj:`NotImplemented` signals that the backend does not support
+Returning :obj:`NotImplemented` signals that the backend does not support the
 conversion of the given object.
 
 :obj:`skip_backend`
 -------------------
 
-If a backend consumes multimethods from a domain, and provides multimethods
+If a backend consumes multimethods from a domain and provides multimethods
 for that same domain, it may wish to have the ability to use multimethods while
 excluding itself from the list of tried backends in order to avoid infinite
 recursion. This allows the backend to implement its functions in terms of
@@ -70,7 +70,7 @@ The process that takes place when the backend is tried
 ------------------------------------------------------
 
 First of all, the backend's ``__ua_convert__`` method is tried. If this returns
-:obj:`NotImplemented`, then the backend is skipped, otherwise its
+:obj:`NotImplemented`, then the backend is skipped, otherwise, its
 ``__ua_function__`` protocol is tried. If a value other than
 :obj:`NotImplemented` is returned, it is assumed to be the final
 return value. Any exceptions raised are propagated up the call stack, except a

docs/multimethod_docs.rst

@@ -72,4 +72,4 @@ Examples
 Examples of writing multimethods are found in `this file <https://github.com/Quansight-Labs/unumpy/blob/master/unumpy/_multimethods.py>`_.
 It also teaches some advanced techniques, such as overriding instance methods,
 including ``__call__``. The same philosophy may be used to override properties,
-static methods and class methods.
+static methods, and class methods.