diff --git a/doc/Language/syntax.pod6 b/doc/Language/syntax.pod6
index ee77a8db4..a7cdd13c8 100644
--- a/doc/Language/syntax.pod6
+++ b/doc/Language/syntax.pod6
@@ -62,11 +62,11 @@ though you can't leave out any of the remaining whitespace.
 =head2 X<Unspace|syntax,\>
 X<|syntax,Unspace>
 
-In many places where the compiler would not allow a space you can use any
-whitespace that is quoted with a backslash. Unspaces in tokens are not
-supported. Newlines that are unspaced still count when the compiler produces
-line numbers. Use cases for unspace are separation of postfix operators and
-routine argument lists.
+In many places where the compiler would not allow a space you can use
+any whitespace that is quoted with a backslash. Unspaces in tokens are
+not supported. Newlines that are unspaced still count when the compiler
+produces line numbers. Use cases for unspace are separation of postfix
+operators and routine argument lists.
 
     sub alignment(+@l) { +@l };
     sub long-name-alignment(+@l) { +@l };
@@ -74,7 +74,7 @@ routine argument lists.
     long-name-alignment(3,5)\   .say;
     say Inf+Inf\i;
 
-=head2 Separating Statements with Semicolons
+=head2 Separating statements with semicolons
 
 A Perl 6 program is a list of statements, separated by semicolons C<;>.
 
@@ -83,8 +83,8 @@ say "Hello";
 say "world";
 =end code
 
-A semicolon after the final statement (or after the final statement inside a
-block) is optional.
+A semicolon after the final statement (or after the final statement
+inside a block) is optional.
 
 =begin code
 say "Hello";
@@ -98,39 +98,39 @@ if True {
 say "world"
 =end code
 
-=head2 Implied Separator Rule (for statements ending in blocks)
+=head2 Implied separator rule (for statements ending in blocks)
 
-Complete statements ending in bare blocks can omit the trailing semicolon, if no
-additional statements on the same line follow the block's closing curly
-brace C<}>. This is called the "implied separator rule". For example, you
-don't need to write a semicolon after an C<if> statement block as seen above, and
-below.
+Complete statements ending in bare blocks can omit the trailing
+semicolon, if no additional statements on the same line follow the
+block's closing curly brace C<}>. This is called the "implied separator
+rule". For example, you don't need to write a semicolon after an C<if>
+statement block as seen above, and below.
 
 =begin code
 if True { say "Hello" }
 say "world";
 =end code
 
-However, semicolons are required to separate a block from trailing statements in
-the same line.
+However, semicolons are required to separate a block from trailing
+statements in the same line.
 
 =begin code
 if True { say "Hello" }; say "world";
 #                     ^^^ this ; is required
 =end code
 
-This implied statement separator rule applies in other ways, besides control
-statements, that could end with a bare block. For example, in combination with
-the colon C<:> syntax for method calls.
+This implied statement separator rule applies in other ways, besides
+control statements, that could end with a bare block. For example, in
+combination with the colon C<:> syntax for method calls.
 
 =begin code
 my @names = <Foo Bar Baz>;
 my @upper-case-names = @names.map: { .uc }    # OUTPUT: [FOO BAR BAZ]
 =end code
 
-For a series of blocks that are part of the same C<if>/C<elsif>/C<else> (or similar)
-construct, the implied separator rule only applies at the end of the last block of that series.
-These three are equivalent:
+For a series of blocks that are part of the same C<if>/C<elsif>/C<else>
+(or similar) construct, the implied separator rule only applies at the
+end of the last block of that series. These three are equivalent:
 
 =begin code
 if True { say "Hello" } else { say "Goodbye" }; say "world";
@@ -193,9 +193,11 @@ say "No more";
 =end code
 
 Brackets inside the comment can be nested, so in C<#`{ a { b } c }>, the
-comment goes until the very end of the string. You may also use more complex
-brackets, such as C<#`{{ double-curly-brace }}>, which might help disambiguate
-from nested brackets. You can embed these comments in expressions, as long as you don't insert them in the middle of keywords or identifiers.
+comment goes until the very end of the string. You may also use more
+complex brackets, such as C<#`{{ double-curly-brace }}>, which might
+help disambiguate from nested brackets. You can embed these comments in
+expressions, as long as you don't insert them in the middle of keywords
+or identifiers.
 
 =head3 Pod comments
 
@@ -372,18 +374,19 @@ variables:
 
 =head2 Packages and Qualified Names
 
-Named entities, such as variables, constants, classes, modules, subs, etc, are
-part of a namespace. Nested parts of a name use C<::> to separate the
-hierarchy. Some examples:
+Named entities, such as variables, constants, classes, modules or subs,
+are part of a namespace. Nested parts of a name use C<::> to separate
+the hierarchy. Some examples:
 
-    =begin code :skip-test
-    $foo                # simple identifiers
-    $Foo::Bar::baz      # compound identifiers separated by ::
-    $Foo::($bar)::baz   # compound identifiers that perform interpolations
-    Foo::Bar::bob(23)   # function invocation given qualified name
-    =end code
+=begin code :skip-test
+$foo                # simple identifiers
+$Foo::Bar::baz      # compound identifiers separated by ::
+$Foo::($bar)::baz   # compound identifiers that perform interpolations
+Foo::Bar::bob(23)   # function invocation given qualified name
+=end code
 
-See the L<documentation on packages|/language/packages> for more details.
+See the L<documentation on packages|/language/packages> for more
+details.
 
 
 =head2 Literals