Remove spaces around operators and reflow

doc/Language/statement-prefixes.pod6

@@ -65,12 +65,12 @@ This code is around 3x faster than the bare for. But there are a couple of
 caveats here:
 
 =item The operation inside the loop should take enough time to make threading
-make sense.
+makes sense.
 
 =item There should be no read or write access to the same data structure inside
 the loop. Let the loop produce a result, and assign it.
 
-=item If there's I/O operation inside the loop, there might be some contention
+=item If there's an I/O operation inside the loop, there might be some contention
 so please avoid it.
 
 Main difference between C<hyper> and C<race> is the ordering of results. Use
@@ -112,7 +112,7 @@ my $result = do for ^5 { $counter++ };
 say $counter; # OUTPUT: «5␤»
 say $result;  # OUTPUT: «(0 1 2 3 4)␤»
 
-C<do> is equivalent, in this an other cases, to surrounding a statement with a
+C<do> is equivalent, as in other cases, to surrounding a statement with a
 parenthesis. It can be used as an alternative with a (possibly more)
 straightforward syntax.
 
@@ -130,7 +130,7 @@ say $result;  #  OUTPUT: «(Any)␤»
 
 =head2 X<C<once>|once (statement prefix)>
 
-Within a loop, runs the prefixed statement only Once
+Within a loop, runs the prefixed statement only once.
 
 =for code
 my $counter;

doc/Language/subscripts.pod6

@@ -40,8 +40,8 @@ B<Associative> subscripting (via L<C<postcircumfix { }>|
 /language/operators#postcircumfix_{_}>), does not require the collection to
 keep its elements in any particular order - instead, it uses a unique key to
 address each value. The nature of the keys depends on the collection in
-question: For example a standard L<Hash|/type/Hash> uses string keys, whereas a L<Mix|/type/Mix>
-allows arbitrary objects as keys, etc.:
+question: For example a standard L<Hash|/type/Hash> uses string keys, whereas
+a L<Mix|/type/Mix> allows arbitrary objects as keys, etc.:
 
     my %grade = Zoe => "C", Ben => "B+";
     say %grade{"Zoe"};  # OUTPUT: «C␤»
@@ -68,14 +68,14 @@ C<{ }> form at compile-time:
     =end code
 
 You may have noted above that we avoided having to quote C<Zoe> by using
-the C<< => >> operator, but that same operator did not just put invisible
+the C«=>» operator, but that same operator did not just put invisible
 quotes around C<Date.new(2015,  4,  5)>, and we were able to find the
 same element using C<$stats{ Date.new(2015, 4, 4) + 1 }>.  This is because
-C<< => >> only puts invisible quotes around single words, and by "word" we
-mean an identifier/name.  The C<< => >> operator is there to prevent us from
+C«=>» only puts invisible quotes around single words, and by "word" we
+mean an identifier/name.  The C«=>» operator is there to prevent us from
 accidentally calling functions or using constants with that name.
 
-Hash subscripts do not do the same thing as C<< => >>.  The default C<Hash>
+Hash subscripts do not do the same thing as C«=>».  The default C<Hash>
 has been made to behave the way new users have come to expect
 from using other languages, and for general ease of use.  On a
 default C<Hash>, subscripts coerce keys into strings, as long as
@@ -89,7 +89,7 @@ collection to be sure whether the keys are strings or objects:
     ( pi => 1 ).perl.say;            # OUTPUT: «:pi(1)␤»
     my %h; %h{pi}  = 1; say %h.perl; # OUTPUT: «{ "3.14159265358979" => 1 }␤»
 
-While the invisible quotes around single names is built into C<< => >>,
+While the invisible quotes around single names is built into C«=>»,
 string conversion is not built into the curly braces: it is a behavior
 of the default C<Hash>.  Not all types of hashes or collections
 do so:
@@ -98,7 +98,7 @@ do so:
 my %h := MixHash.new;
 %h{pi} = 1; %h.perl.say;         # OUTPUT: «(3.14159265358979e0=>1).MixHash␤»
 
-(Any name that C<< => >> would convert to a string can also be used to build
+(Any name that C«=>» would convert to a string can also be used to build
 a pair using "adverbial notation" and will appear that way when viewed
 through C<.perl>, which is why we see C<:pi(1)> above.)
 
@@ -126,7 +126,7 @@ to an object that does not implement support for them.)
 
 =head1 Nonexistent elements
 
-What happens when a I<nonexistent> element is addressed by a subscript, is up to
+What happens when a I<nonexistent> element is addressed by a subscript is up to
 the collection type in question. Standard L<Array|/type/Array> and
 L<Hash|/type/Hash> collections return the type object of their L<value type
 constraint|of> (which, by default, is L<Any|/type/Any>) unless the collection
@@ -235,9 +235,11 @@ In particular the I<type> can be any of the following:
 
 =item any iterable different from the above ones, normal slice
 
-The notable difference between C<*> and Zen slice (empty) is that the L<Whatever|/type/Whatever> star
-will cause full L<reification|/language/glossary#index-entry-Reify>, while Zen slice won't.
-Both versions also L<de-cont|https://perl6advent.wordpress.com/2017/12/02/perl-6-sigils-variables-and-containers/#decont>.
+The notable difference between C<*> and Zen slice (empty) is that the
+L<Whatever|/type/Whatever> star will cause full
+L<reification|/language/glossary#index-entry-Reify>, while Zen slice won't.
+Both versions also
+L<de-cont|https://perl6advent.wordpress.com/2017/12/02/perl-6-sigils-variables-and-containers/#decont>.
 
 So even a one-element list returns a slice, whereas a bare scalar value doesn't:
 
@@ -251,7 +253,8 @@ So even a one-element list returns a slice, whereas a bare scalar value doesn't:
 
 (The angle bracket form for associative subscripts works out because
 L<word quoting|/language/quoting#Word_quoting:_qw> conveniently returns a
-L<Str|/type/Str> in case of a single word, but a L<List|/type/List> in case of multiple words.)
+L<Str|/type/Str> in case of a single word, but a L<List|/type/List> in case
+of multiple words.)
 
 In fact, the list structure of (L<the current dimension of|#Multiple
 dimensions>) the subscript is preserved across the slice operation
@@ -1002,7 +1005,7 @@ to return non-container values directly.
 Expected to return a Bool indicating whether or not there is an element
 associated with C<$key>. This is what L<C<postcircumfix { }>
 |/routine/{ }#postcircumfix_{_}> calls when invoked like
-C<< %foo<aa>:exists >>.
+C<<%foo<aa>:exists>>.
 
 What "existence" of an element means, is up to your type.
 
@@ -1022,7 +1025,7 @@ silently doing the wrong thing.
 Expected to delete the element associated with C<$key>, and return the
 value it had. This is what L<C<postcircumfix { }>
 |/routine/{ }#postcircumfix_{_}> calls when invoked like
-C<< %foo<aa>:delete >>.
+C<<%foo<aa>:delete>>.
 
 What "deleting" an element means, is up to your type - though it should
 usually cause C<EXISTS-KEY> to become C<False> for that key.
@@ -1043,13 +1046,13 @@ $new> is used instead, and if you do, you should make sure it has the same
 effect.
 
 This is meant as an opt-in performance optimization, so that simple
-assignments C<< %age<Claire> = 29 >> can operate without having to call
+assignments C<<%age<Claire> = 29>> can operate without having to call
 C<AT-KEY> (which would have to create and return a potentially expensive
 container object).
 
 Note that implementing C<ASSIGN-KEY> does I<not> relieve you from making
 C<AT-KEY> an C<rw> method though, because less trivial
-assignments/modifications such as C<< %age<Claire>++ >> will still use
+assignments/modifications such as C<<%age<Claire>++>> will still use
 C<AT-KEY>.
 
 =head3 method BIND-KEY