Apply suggestions from review

Signed-off-by: Ben Sherman <[email protected]>

Author: bentsherman

docs/config.md

@@ -48,7 +48,7 @@ params.helper_file = "${projectDir}/assets/helper.txt"
 
 ### Blocks
 
-A config scope can also be specified as a block, allowing multiple configuration options to be set within that block. For example:
+A config scope can also be specified as a block, which may contain multiple configuration options. For example:
 
 ```groovy
 // dot syntax

docs/process.md

@@ -260,7 +260,7 @@ Hello Mr. a
 Hello Mr. c
 ```
 
-A native process is very similar to a {ref}`function <syntax-function>`, but provides additional capabilities such as parallelism, caching, and progress logging.
+A native process is very similar to a {ref}`function <syntax-function>`. However, it provides additional capabilities such as parallelism, caching, and progress logging.
 
 (process-stub)=
 

docs/reference/syntax.md

@@ -37,7 +37,7 @@ A Nextflow script may contain the following top-level declarations:
 
 Script declarations are in turn composed of statements and expressions.
 
-A script may contain one or more [statements](#statements), if there are no top-level declarations. In this case, the entire script will be treated as an entry workflow. For example:
+If there are no top-level declarations, a script may contain one or more [statements](#statements), in which case the entire script is treated as an entry workflow. For example:
 
 ```groovy
 println 'Hello world!'
@@ -65,7 +65,7 @@ The first line of a script can be a [shebang](https://en.wikipedia.org/wiki/Sheb
 
 ### Feature flag
 
-A feature flag declaration is an assignment, where the target should be a valid {ref}`feature flag <config-feature-flags>` and the source should be a literal (i.e. number, string, boolean):
+A feature flag declaration is an assignment. The target should be a valid {ref}`feature flag <config-feature-flags>` and the source should be a literal (i.e. number, string, boolean):
 
 ```groovy
 nextflow.preview.topic = true
@@ -79,7 +79,7 @@ An include declaration consists of an *include source* and one or more *include
 include { foo as bar } from './some/module'
 ```
 
-The include source should be a string literal and should refer to either a local path (e.g. `./module.nf`) or a plugin (e.g. `plugin/nf-hello`). Each include clause should specify a name, and may also specify an *alias*. In the example above, `foo` is included under the alias `bar`.
+The include source should be a string literal and should refer to either a local path (e.g. `./module.nf`) or a plugin (e.g. `plugin/nf-hello`). Each include clause should specify a name, and may also specify an *alias*. In the above example, `foo` is included under the alias `bar`.
 
 Include clauses can be separated by semi-colons or newlines:
 
@@ -109,7 +109,7 @@ The following definitions can be included:
 
 ### Parameter
 
-A parameter declaration is an assignment, where the target should be a pipeline parameter and the source should be an expression:
+A parameter declaration is an assignment. The target should be a pipeline parameter and the source should be an expression:
 
 ```groovy
 params.message = 'Hello world!'
@@ -404,7 +404,7 @@ Multiple variables can be assigned in a single statement as long as the source e
 
 Any [expression](#expressions) can be a statement.
 
-In general, the only expressions that can have any effect as expression statements are function calls that have side effects (e.g. `println`) or an implicit return statement (e.g. in a function or closure).
+In general, the only expressions that can have any effect as expression statements are function calls that have side effects (e.g. `println`) or an implicit return statement in a [function](#function) or [closure](#closure).
 
 ### assert
 
@@ -693,7 +693,7 @@ A list literal consists of a comma-separated list of zero or more expressions, e
 
 ### Map
 
-A map literal consists of a comma-separated list of one or more *map entries*, where each map entry consists of a *key expression* and *value expression* separated by a colon, enclosed in square brackets:
+A map literal consists of a comma-separated list of one or more *map entries*, enclosed in square brackets. Each map entry consists of a *key expression* and *value expression* separated by a colon:
 
 ```groovy
 [foo: 1, bar: 2, baz: 3]
@@ -952,6 +952,6 @@ Compound expressions are evaluated in the following order:
 
 The following legacy features were excluded from this page because they are deprecated:
 
-- The `addParams` and `params` clauses of include declarations (see {ref}`module-params`)
-- The `when:` section of a process definition (see {ref}`process-when`)
+- The `addParams` and `params` clauses of include declarations. See {ref}`module-params` for more information.
+- The `when:` section of a process definition. See {ref}`process-when` for more information.
 - The implicit `it` closure parameter

docs/script.md

@@ -2,7 +2,7 @@
 
 # Scripts
 
-Nextflow is a workflow language that runs on the Java virtual machine (JVM). Nextflow's syntax is very similar to [Groovy](https://groovy-lang.org/), a scripting language for the JVM, but Nextflow is specialized for writing computational pipelines in a declarative manner. See {ref}`syntax-page` for a full description of the Nextflow language.
+Nextflow is a workflow language that runs on the Java virtual machine (JVM). Nextflow's syntax is very similar to [Groovy](https://groovy-lang.org/), a scripting language for the JVM. However, Nextflow is specialized for writing computational pipelines in a declarative manner. See {ref}`syntax-page` for a full description of the Nextflow language.
 
 Nextflow scripts can also make full use of the Java and Groovy standard libraries. See {ref}`stdlib-page` for more information.
 
@@ -45,7 +45,7 @@ println str
 ```
 
 :::{warning}
-Variables can also be declared without `def` in many cases, but this practice is discouraged outside of simple code snippets because it can lead to a {ref}`race condition <cache-global-var-race-condition>`.
+Variables can also be declared without `def` in some cases. However, this practice is discouraged outside of simple code snippets because it can lead to a {ref}`race condition <cache-global-var-race-condition>`.
 :::
 
 ## Lists
@@ -311,7 +311,7 @@ println square(9)
 
 The above example prints `81`.
 
-The main use case for a closure, however, is as an argument to a higher-order function:
+The main use case for a closure is as an argument to a higher-order function:
 
 ```groovy
 [ 1, 2, 3, 4 ].collect(square)
@@ -380,7 +380,7 @@ This way, the closure is fully "self-contained" because it doesn't access or mut
 
 So far, we have been focusing on the basic building blocks of Nextflow code, like variables, lists, strings, and closures.
 
-In practice, however, Nextflow scripts are composed of *workflows*, *processes*, and *functions* (collectively known as *definitions*), and they can *include*  definitions from other scripts.
+In practice, however, Nextflow scripts are composed of *workflows*, *processes*, and *functions* (collectively known as *definitions*), and can *include*  definitions from other scripts.
 
 To transition a code snippet into a proper workflow script, simply wrap it in a `workflow` block:
 
@@ -390,7 +390,7 @@ workflow {
 }
 ```
 
-This block is called the *entry workflow*. A script can only have one entry workflow, and it serves as the entrypoint when the script is executed. In fact, whenever a script contains only simple statements like `println 'Hello!'`, Nextflow simply treats it as an entry workflow!
+This block is called the *entry workflow*. It serves as the entrypoint when the script is executed. A script can only have one entry workflow. Whenever a script contains only simple statements like `println 'Hello!'`, Nextflow simply treats it as an entry workflow.
 
 You can also break up code into functions, for example: