small wording tweaks

Author: adqm

peps/pep-0798.rst

@@ -131,7 +131,7 @@ Specification
 Syntax
 ------
 
-The necessary grammatical changes are allowing the expression in list/set
+The grammar should be changed to allow the expression in list/set
 comprehensions and generator expressions to be preceded by a ``*``, and
 allowing an alternative form of dictionary comprehension in which a
 double-starred expression can be used in place of a ``key: value`` pair.
@@ -217,7 +217,7 @@ Semantics: Generator Expressions
 Generator expressions using the unpacking syntax should form new generators
 producing values from the concatenation of the iterables given by the
 expressions.  Specifically, the behavior is defined to be equivalent to the
-following (though without defining for referencing the looping variable
+following (though without defining or referencing the looping variable
 ``i``)::
 
     # equivalent to generator = (*expr for x in it)
@@ -655,7 +655,7 @@ resulting generator, but several alternatives were suggested in our discussion
   other aspects of this proposal are accepted.
 
 The reason to prefer this proposal over these alternatives is the preservation
-of existent conventions for punctuation around generator expressions.
+of existing conventions for punctuation around generator expressions.
 Currently, the general rule is that generator expressions must be wrapped in
 parentheses except when provided as the sole argument to a function, and this
 proposal suggests maintaining that rule even as we allow more kinds of
@@ -794,7 +794,7 @@ were raised as well. This section aims to summarize those concerns.
   Complex uses of unpacking in comprehensions could obscure logic that would be
   clearer in an explicit loop.  While this is already a concern with
   comprehensions more generally, the addition of ``*`` and ``**`` may make
-  particularly-complex uses even more difficult to read and understand at a
+  particularly complex uses even more difficult to read and understand at a
   glance.  For example, while these situations are likely rare, comprehensions
   that use unpacking in multiple ways can make it difficult to know what's
   being unpacked and when: ``f(*(*x for *x, _ in list_of_lists))``.
@@ -840,7 +840,7 @@ Many languages that support comprehensions support double loops:
     (for [xs [[1 2 3] [] [4 5]] x (concat xs xs)] x)
 
 Several other languages (even those without comprehensions) support these
-operations via a built-in function/method to support flattening of nested
+operations via a built-in function or method to support flattening of nested
 structures:
 
 .. code:: python
@@ -850,7 +850,7 @@ structures:
 
 .. code:: javascript
 
-    // Javascript
+    // JavaScript
     [[1,2,3], [], [4,5]].flatMap(xs => [...xs, ...xs])
 
 .. code:: haskell
@@ -873,7 +873,7 @@ in Julia currently leads to a syntax error:
 
 As one counterexample, support for a similar syntax was recently added to `Civet
 <https://civet.dev/>`_.  For example, the following is a valid comprehension in
-Civet, making use of Javascript's ``...`` syntax for unpacking:
+Civet, making use of JavaScript's ``...`` syntax for unpacking:
 
 .. code:: javascript