Revised a couple of sections.

sections/chapter_03.pod

@@ -1,11 +1,11 @@
 =head0 The Perl Language
 
-The Perl language has several smaller parts which combine to form its syntax.
-Unlike spoken language, where nuance and tone of voice and intuition allow
-people to communicate despite slight misunderstandings and fuzzy concepts,
-computers and source code require precision.  You can write effective Perl code
-without knowing every detail of every language feature, but you must understand
-how they work together to write Perl code well.
+Like a spoken language, the whole of Perl is a combination of several smaller
+but interrelated parts. Unlike spoken language, where nuance and tone of voice
+and intuition allow people to communicate despite slight misunderstandings and
+fuzzy concepts, computers and source code require precision. You can write
+effective Perl code without knowing every detail of every language feature, but
+you must understand how they work together to write Perl code well.
 
 L<names>
 

sections/names.pod

@@ -6,11 +6,11 @@ X<names>
 X<identifiers>
 
 I<Names> (or I<identifiers>) are everywhere in Perl programs: variables,
-functions, packages, classes, and even filehandles have names.  These names all
-start with a letter or an underscore.  They may optionally include any
-combination of letters, numbers, and underscores.  When the C<utf8> pragma
-(L<unicode>) is in effect, you may use any valid UTF-8 characters in
-identifiers.  These are all valid Perl identifiers:
+functions, packages, classes, and even filehandles. These names all begin with
+a letter or an underscore and may optionally include any combination of
+letters, numbers, and underscores.  When the C<utf8> pragma (L<unicode>) is in
+effect, you may use any valid UTF-8 characters in identifiers. These are all
+valid Perl identifiers:
 
 =begin programlisting
 
@@ -39,18 +39,20 @@ These are invalid Perl identifiers:
 
 X<symbolic lookups>
 
-These rules only apply to names which appear in literal form in source code;
-that is, if you've typed it directly like C<sub fetch_pie> or C<my
-$waffleiron>.
+I<Names exist primarily for the benefit of the programmer>. These rules apply
+only to literal names which appear as-is in your source code, such as C<sub
+fetch_pie> or C<my $waffleiron>. Only Perl's parser enforces the rules about
+indentifier names.
 
-Perl's dynamic nature makes it possible to refer to entities with names
-generated at runtime or provided as input to a program.  These are I<symbolic
-lookups>.  You get more flexibility this way at the expense of some safety.  In
-particular, invoking functions or methods indirectly or looking up symbols in a
-namespace lets you bypass Perl's parser, which is the only part of Perl that
-enforces these grammatical rules.  Be aware that doing so can produce confusing
-code; a hash (L<hashes>) or nested data structure (L<nested_data_structures>)
-is often clearer.
+Perl's dynamic nature allows you to refer to entities with names generated at
+runtime or provided as input to a program. These I<symbolic lookups> provide
+flexibility at the expense of some safety. In particular, invoking functions or
+methods indirectly or looking up symbols in a namespace lets you bypass Perl's
+parser.
+
+Doing so can produce confusing code. As Mark Jason Dominus recommends so
+effectivelyN<U<http://perl.plover.com/varvarname.html>>, use a hash (L<hashes>)
+or nested data structure (L<nested_data_structures>).
 
 =head2 Variable Names and Sigils
 
@@ -62,11 +64,12 @@ X<arrays>
 X<variables; arrays>
 X<hashes>
 X<variables; hashes>
+X<sigil>
 
-I<Variable names> always have a leading sigil which indicates the type of the
-variable's value.  I<Scalar variables> (L<scalars>) have a leading dollar sign
-(C<$>) character.  I<Array variables> (L<arrays>) have a leading at sign (C<@>)
-character.  I<Hash variables> (L<hashes>) have a leading percent sign (C<%>)
+I<Variable names> always have a leading I<sigil> (or symbol) which indicates
+the type of the variable's value. I<Scalar variables> (L<scalars>) use the
+dollar sign (C<$>) character. I<Array variables> (L<arrays>) use the at sign
+(C<@>) character. I<Hash variables> (L<hashes>) use the percent sign (C<%>)
 character:
 
 =begin programlisting
@@ -77,8 +80,8 @@ character:
 
 =end programlisting
 
-In one sense, these sigils offer namespaces of the variables, where it's
-possible (though often confusing) to have variables of the same name but
+These sigils provide a visual namespacing for variable names. It's
+possible--though confusing--to declare multiple variables of the same name with
 different types:
 
 =begin programlisting
@@ -87,13 +90,15 @@ different types:
 
 =end programlisting
 
-Perl won't get confused, but people reading the code might.
+Again, names exist to help programmers. Perl won't get confused. People reading
+this code will.
 
 X<variant sigils>
 
-Perl 5 uses I<variant sigils>, where the sigil on a variable may change
-depending on what you do with it.  For example, to access an element of an
-array or a hash, the sigil changes to the scalar sigil (C<$>):
+Perl 5's sigils are I<variant sigils>. As context determines how many items you
+expect from an operation or what type of data you expect to get, so the sigil
+governs how you manipulate the data of a variable.  For example, to access a
+single element of an array or a hash, you must use the scalar sigil (C<$>):
 
 =begin programlisting
 
@@ -108,16 +113,16 @@ array or a hash, the sigil changes to the scalar sigil (C<$>):
 X<lvalue>
 X<rvalue>
 
-In the latter two lines, using a scalar element of an aggregate as an I<lvalue>
-(the target of an assignment, on the left side of the C<=> character) imposes
-scalar context (L<context_philosophy>) on the I<rvalue> (the value assigned, on
-the right side of the C<=> character).
+The parallel with amount context is important. Using a scalar element of an
+aggregate as an I<lvalue> (the target of an assignment, on the left side of the
+C<=> character) imposes scalar context (L<context_philosophy>) on the I<rvalue>
+(the value assigned, on the right side of the C<=> character).
 
 X<slices>
 
 Similarly, accessing multiple elements of a hash or an array--an operation
-known as I<slicing>--uses the at symbol (C<@>) as the leading sigil and
-imposes list context:
+known as I<slicing>--uses the at symbol (C<@>) and imposes list contextN<...
+even if the list itself has zero or one elements>:
 
 =begin programlisting
 
@@ -130,32 +135,37 @@ imposes list context:
 =end programlisting
 
 The most reliable way to determine the type of a variable--scalar, array, or
-hash--is to look at the operations performed on it.  Scalars support all basic
-operations, such as string, numeric, and boolean manipulations.  Arrays support
-indexed access through square brackets.  Hashes support keyed access through
+hash--is to look at the operations performed on it. Scalars support all basic
+operations, such as string, numeric, and boolean manipulations. Arrays support
+indexed access through square brackets. Hashes support keyed access through
 curly brackets.
 
-=head2 Package-Qualified Names
+=head2 Namespaces
 
 X<fully-qualified name>
-
-Occasionally you may need to refer to functions or variables in a separate
-namespace.  Often you will need to refer to a class by its I<fully-qualified
-name>.  These names are collections of package names joined by double colons
-(C<::>).  That is, C<My::Fine::Package> refers to a logical collection of
-variables and functions.
-
-While the standard naming rules apply to package names, by convention
-user-defined packages all start with uppercase letters.  The Perl core reserves
-lowercase package names for core pragmas (L<pragmas>), such as C<strict> and
-C<warnings>.  This is a policy enforced by community guidelines instead of Perl
-itself.
-
-Namespaces do not nest in Perl 5.  The relationship between
-C<Some::Package> and C<Some::Package::Refinement> is only a storage mechanism,
-with no further implications on the relationships between parent and child or
-sibling packages.  When Perl looks up a symbol in C<Some::Package::Refinement>,
-it looks in the C<main::> symbol table for a symbol representing the C<Some::>
-namespace, then in there for the C<Package::> namespace, and so on.  It's your
-responsibility to make any I<logical> relationships between entities obvious
-when you choose names and organize your code.
+X<namespaces>
+
+Perl provides a mechanism to group similar functions and variables into their
+own unique named spaces--I<namespaces> (L<packages>). A namespace is a
+collection of one or more names joined by double colons (C<::>), such that
+C<DessertShop::IceCream> refers to a logical collection of related variables and
+functions, such as C<scoop()> and C<pour_hot_fudge()>.
+
+Within a namespace, you may use the short name of its members. Outside of the
+namespace, refer to a member using its I<fully-qualified name>, which includes
+the namespace, as in C<DessertShop::IceCream::add_sprinkles()>.
+
+While standard naming rules apply to package names, by convention user-defined
+packages all start with uppercase letters. The Perl core reserves lowercase
+package names for core pragmas (L<pragmas>), such as C<strict> and C<warnings>.
+This is a policy enforced primarily by community guidelines.
+
+Namespaces do not nest in Perl 5. The relationship between
+C<DessertShop::IceCream> and C<DessertShop::IceCream::Freezer> is only a
+storage mechanism, with no further implications on the relationships between
+parent and child or sibling packages. When Perl looks up a symbol in
+C<DessertShop::IceCream::Freezer>, it looks in the C<main::> symbol table for a
+symbol representing the C<DessertShop::> namespace, then in there for the
+C<IceCream::> namespace, and so on. Only a programmer can make I<logical>
+relationships between entities obvious--by choosing good names and organizing
+them well.