Wrap paragraphs consistently in mop.pod

Author: paultcochrane

lib/Language/mop.pod

@@ -4,9 +4,9 @@
 
 =SUBTITLE Introspection and the Perl 6 Object System
 
-Perl 6 is built on a meta object layer. That means that there are objects (the
-I<meta objects>) that control how various object-oriented constructs (such as
-classes, roles, methods, attributes, enums, ...) behave.
+Perl 6 is built on a meta object layer. That means that there are objects
+(the I<meta objects>) that control how various object-oriented constructs
+(such as classes, roles, methods, attributes, enums, ...) behave.
 
 To get a feeling for the meta object for C<class>, here is the same example
 twice: once as normal declarations in Perl 6, and once expressed through the
@@ -29,29 +29,28 @@ corresponds to:
 (except that the declarative form runs at comple time, and the latter form
 does not).
 
-The meta object behind
-an object can be obtained with C<$obj.HOW>, where HOW stands for Higher Order
-Workings (or, I<HOW the *%@$ does this work?>).
+The meta object behind an object can be obtained with C<$obj.HOW>, where HOW
+stands for Higher Order Workings (or, I<HOW the *%@$ does this work?>).
 
-Here, the calls with C<.^> are calls to the meta object, so C<A.^compose> is a
-shortcut for C<A.HOW.compose(A)>. The invocant is passed in the
-parameter list as well, to make it possible to support prototype-style type
-systems, where there is just one meta object (and not one meta object per
-type, as standard Perl 6 does it).
+Here, the calls with C<.^> are calls to the meta object, so C<A.^compose> is
+a shortcut for C<A.HOW.compose(A)>. The invocant is passed in the parameter
+list as well, to make it possible to support prototype-style type systems,
+where there is just one meta object (and not one meta object per type, as
+standard Perl 6 does it).
 
-As the example above demonstrates, all object oriented features are available
-to the user, not just to the compiler. In fact the compiler just uses
-such calls to meta objects.
+As the example above demonstrates, all object oriented features are
+available to the user, not just to the compiler. In fact the compiler just
+uses such calls to meta objects.
 
 =head1 Metamethods
 
 These are introspective macros that resemble method calls.
 
 Metamethods are generally named with ALLCAPS, and it is considered good
 style to avoid using your own methods with ALLCAPS names.  This will avoid
-conflicts with any metamethods that may appear in future versions of
-the language.  Note that if you really must use a method which has an
-ALLCAPS name, use quotes around the method name to safely call it indirectly:
+conflicts with any metamethods that may appear in future versions of the
+language.  Note that if you really must use a method which has an ALLCAPS
+name, use quotes around the method name to safely call it indirectly:
 
     #| THIS IS A CLASS FOR SHOUTING THINGS
     class MY-CLASSES-ARE-ALL-CAPS {
@@ -79,8 +78,8 @@ The package supporting the object.
 =head2 X<WHERE|syntax,WHERE>
 
 The memory address of the object. Note that this is not stable in
-implementations with moving/compacting garbage collectors. Use C<WHICH> for a
-stable identity indicator.
+implementations with moving/compacting garbage collectors. Use C<WHICH> for
+a stable identity indicator.
 
 =head2 X<HOW|syntax,HOW>
 
@@ -119,27 +118,26 @@ class in the C<Metamodel::> namespace. (Rakudo implements them in the
 C<Perl6::Metamodel::> namespace, and then maps C<Perl6::Metamodel> to
 C<Metamodel>).
 
-Many of the these meta classes share common functionality. For example roles,
-grammars and classes can all contain methods and attributes, as well as being
-able to do roles.
-This shared functionality is implemented in roles which are composed into the
-appropriate meta classes. For example
-L<role Metamodel::RoleContainer|/type/Metamodel::RoleContainer> implements the
-functionality that a type can hold roles and
+Many of the these meta classes share common functionality. For example
+roles, grammars and classes can all contain methods and attributes, as well
+as being able to do roles.  This shared functionality is implemented in
+roles which are composed into the appropriate meta classes. For example
+L<role Metamodel::RoleContainer|/type/Metamodel::RoleContainer> implements
+the functionality that a type can hold roles and
 L<Metamodel::ClassHOW|/type/Metamodel::ClassHOW>, which is the meta class
 behind the C<class> keyword, does this role.
 
 =head2 Bootstrapping concerns
 
-You might wonder how C<Metamodel::ClassHOW> can be a class, when being a class
-is defined in terms of C<Metamodel::ClassHOW>, or how the roles responsible
-for role handling can be roles. The answer is I<by magic>.
+You might wonder how C<Metamodel::ClassHOW> can be a class, when being a
+class is defined in terms of C<Metamodel::ClassHOW>, or how the roles
+responsible for role handling can be roles. The answer is I<by magic>.
 
 Just kidding. Bootstrapping is implementation specific. Rakudo does it by
-using the object system of the language in which itself is implemented, which
-happens to be (nearly) a subset of Perl 6: NQP, Not Quite Perl. NQP has a
-primitive, class-like kind called C<knowhow>, which is used to bootstrap its
-own classes and roles implementation. C<knowhow> is built on primitives that
-the virtual machine under NQP provides.
+using the object system of the language in which itself is implemented,
+which happens to be (nearly) a subset of Perl 6: NQP, Not Quite Perl. NQP
+has a primitive, class-like kind called C<knowhow>, which is used to
+bootstrap its own classes and roles implementation. C<knowhow> is built on
+primitives that the virtual machine under NQP provides.
 
 =end pod