In language/list: some minor corrections and clarifications (#4685)

* say what parentheses do

* typo

* add example to a sentence that's hard to parse

* space after comma

* add comma in sentence

Corrected punctuation in the explanation of itemization.

Author: schultzdavid

doc/Language/contexts.rakudoc

@@ -241,7 +241,7 @@ $(1,2,3).elems.say;          # OUTPUT: «3␤»
 say (1,2,3).item[2];         # OUTPUT: «3␤»
 say $( key => 'value')<key>; # OUTPUT: «value␤»
 
-Itemization I<containerizes> values in a data structure keeping them, for
+Itemization I<containerizes> values in a data structure, keeping them, for
 instance, from being flattened into the surrounding list or data structure:
 
 =for code

doc/Language/list.rakudoc

@@ -13,7 +13,7 @@ elegant system for handling them.
 =head1 Literal lists
 
 Literal L<C<List>|/type/List>s are created with commas and semicolons, B<not>
-with parentheses, so:
+with parentheses (which only group things), so:
 
     1, 2;                # This is two-element list
     our $list = (1, 2);  # This is also a List, in parentheses
@@ -96,7 +96,7 @@ instead.
 One of the ways C<@>-sigiled variables act like lists is by always supporting
 L<positional subscripting|/language/subscripts>. Anything bound to an
 C<@>-sigiled value must support the L<C<Positional>|/type/Positional> role which
-guarantees that this is going to fail:
+guarantees that the following is going to fail:
 
     my @a := 1; # Type check failed in binding; expected Positional but got Int
 
@@ -166,7 +166,7 @@ would expect>.
 
 This rule is equivalent to saying that arguments to iterators will not
 flatten, will not de-containerize, and will behave as if a single argument
-has been handled to them, whatever the shape that argument has.
+has been handed to them, whatever the shape that argument has.
 
 =for code
 my @a = 1,2; .say for @a, |@a;     # OUTPUT: «[1 2]␤1␤2␤»
@@ -175,7 +175,7 @@ my @a = 1,2; .say for $[@a, |@a ]; # OUTPUT: «[[1 2] 1 2]␤»
 In the second case, the single argument is a single element, since we have
 itemized the array. There's an exception to the single argument rule
 L<mentioned in the Synopsis|https://github.com/Raku/old-design-docs/blob/master/S07-lists.pod#The_single_argument_rule>:
-list or arrays with a single element will be flattened:
+lists or arrays with a single element will be flattened:
 
 =for code
 my @a = 1,2; .say for [[@a ]];     # OUTPUT: «1␤2␤»
@@ -748,12 +748,12 @@ as a courtesy to their users:
 =item Use L<C<Slip>|/type/Slip>s when you want to always merge with surrounding lists.
 =item Use non-itemized lists when you want to make it easy for the user to flatten.
 =item Use itemized lists to protect things the user probably will not want flattened.
-=item Use L<C<Array>|/type/Array>s as non-itemized lists of itemized lists, if appropriate.
+=item Use L<C<Array>|/type/Array>s as non-itemized lists of itemized lists, if appropriate. (E.g. C<[$(1, 2), $(3, 4)]>.)
 =item Use L<C<Array>|/type/Array>s if the user is going to want to mutate the result without copying it first.
 
 The fact that all elements of an array are itemized (in L<C<Scalar>|/type/Scalar>
 containers) is more a gentleman's agreement than a universally enforced
-rule, and it is less well enforced that typechecks in typed arrays.  See
+rule, and it is less well enforced than typechecks in typed arrays.  See
 the section below on binding to Array slots.
 
 =head2 Literal arrays