Documentation improvements: fix typos and grammar

README.md

@@ -53,8 +53,8 @@ no_worldage()
 ## Changing how global symbols are looked up
 
 If you want to use helper functions or global variables from a different
-module within your function expression you'll need to pass a `context_module`
-to the `@RuntimeGeneratedFunction` constructor. For example
+module within your function expression, you'll need to pass a `context_module`
+to the `@RuntimeGeneratedFunction` constructor. For example:
 
 ```julia
 RuntimeGeneratedFunctions.init(@__MODULE__)
@@ -75,14 +75,14 @@ end
 
 ## Precompilation and setting the function expression cache
 
-For technical reasons RuntimeGeneratedFunctions needs to cache the function
+For technical reasons, RuntimeGeneratedFunctions needs to cache the function
 expression in a global variable within some module. This is normally
 transparent to the user, but if the `RuntimeGeneratedFunction` is evaluated
 during module precompilation, the cache module must be explicitly set to the
 module currently being precompiled. This is relevant for helper functions in
-some module which construct a RuntimeGeneratedFunction on behalf of the user.
+some module which constructs a RuntimeGeneratedFunction on behalf of the user.
 For example, in the following code, any third party user of
-`HelperModule.construct_rgf()` user needs to pass their own module as the
+`HelperModule.construct_rgf()` needs to pass their own module as the
 `cache_module` if they want the returned function to work after precompilation:
 
 ```julia

docs/src/index.md

@@ -45,7 +45,7 @@ no_worldage()
 
 If you want to use helper functions or global variables from a different
 module within your function expression, you'll need to pass a `context_module`
-to the `@RuntimeGeneratedFunction` constructor. For example
+to the `@RuntimeGeneratedFunction` constructor. For example:
 
 ```julia
 RuntimeGeneratedFunctions.init(@__MODULE__)
@@ -71,9 +71,9 @@ expression in a global variable within some module. This is normally
 transparent to the user, but if the `RuntimeGeneratedFunction` is evaluated
 during module precompilation, the cache module must be explicitly set to the
 module currently being precompiled. This is relevant for helper functions in
-some module, which construct a RuntimeGeneratedFunction on behalf of the user.
+some module which constructs a RuntimeGeneratedFunction on behalf of the user.
 For example, in the following code, any third party user of
-`HelperModule.construct_rgf()` user needs to pass their own module as the
+`HelperModule.construct_rgf()` needs to pass their own module as the
 `cache_module` if they want the returned function to work after precompilation:
 
 ```julia

src/RuntimeGeneratedFunctions.jl

@@ -65,7 +65,7 @@ struct RuntimeGeneratedFunction{argnames, cache_tag, context_tag, id, B} <: Func
         new{Tuple(args), cache_tag, context_tag, id, typeof(cached_body)}(cached_body)
     end
 
-    # For internal use in deserialize() - doesen't check whether the body is in the cache!
+    # For internal use in deserialize() - doesn't check whether the body is in the cache!
     function RuntimeGeneratedFunction{
             argnames,
             cache_tag,