Fixes links and reflows

Author: JJ

doc/Language/numerics.pod6

@@ -275,7 +275,7 @@ L<Failure>, while L<Complex> division by zero produces C<NaN> components,
 regardlesss of what the numerator is.
 
 As of 6.d language, both L<Num> and L<Complex> division by zero will produce
-a L<-Inf>, L<+Inf>, or L<NaN> depending on whether the numerator was negative, positive, or zero, respectively (for L<Complex> the real and imaginary
+a -L<Inf|/type/Num#Inf>, C<+Inf>, or L<NaN> depending on whether the numerator was negative, positive, or zero, respectively (for L<Complex> the real and imaginary
 components are L<Num> and are considered separately).
 
 Division of L<Int> numerics produces a L<Rat> object (or a L<Num>, if
@@ -553,9 +553,10 @@ say my uint8 @a = 1000, 2000, 3000; # OUTPUT: «232 208 184␤»
 
 =head2 Auto-Boxing
 
-While they can be referred to as "native I<types>", native numerics are not actually classes
-that have any sort of methods available. However, you I<can> call any of the methods available
-on non-native versions of these numerics. What's going on?
+While they can be referred to as "native I<types>", native numerics are not
+actually classes that have any sort of methods available. However, you I<can>
+call any of the methods available on non-native versions of these numerics.
+What's going on?
 
 =begin code
 my int8 $x = -42;
@@ -595,10 +596,11 @@ my int $a-native = -42;
 
 =head2 Default Values
 
-Since there are no classes behind native types, there are no type objects you'd normally get
-with variables that haven't been initialized. Thus, native types are automatically initialized
-to zero. In 6.c language, native floating point types (C<num>, C<num32>, and C<num64>) are
-initialized to value C<NaN>; it is proposed for default to become C<0e0> in 6.d language.
+Since there are no classes behind native types, there are no type objects you'd
+normally get with variables that haven't been initialized. Thus, native types
+are automatically initialized to zero. In 6.c language, native floating point
+types (C<num>, C<num32>, and C<num64>) are initialized to value C<NaN>; it is
+proposed for default to become C<0e0> in 6.d language.
 
 =head2 Native Dispatch
 
@@ -656,26 +658,30 @@ say f $x;
 #   in block <unit> at -e line 1
 =end code
 
-However, this rule is waived if a call is being made where one of the arguments is a native type
-and another one is a L<numeric literal>:
+However, this rule is waived if a call is being made where one of the arguments
+is a native type and another one is a
+L<numeric literal|/syntax/Number literals>:
 
 =begin code
 multi f(int, int) {}
 f 42, my int $x; # Successfull call
 =end code
 
-This way you do not have to constantly write, for example, C«$n +> 2» as C«$n +> (my int $ = 2)».
-The compiler knows the literal is small enough to fit to a native type and converts it to a native.
+This way you do not have to constantly write, for example, C«$n +> 2» as C«$n +>
+(my int $ = 2)». The compiler knows the literal is small enough to fit to a
+native type and converts it to a native.
 
 =head2 Atomic Operations
 
 The language offers L<some operations|https://docs.perl6.org/type/atomicint>
 that are guaranteed to be performed atomically, i.e. safe to be executed
 by multiple threads without the need for locking with no risk of data races.
 
-For such operations, the L<atomicint> native type is required. This type is
-similar to a plain native L<int>, except it is sized such that CPU-provided atomic operations can be performed upon it. On a 32-bit CPU it will typically
-be 32 bits in size, and on an a 64-bit CPU it will typically be 64 bits in size.
+For such operations, the L<atomicint|/type/atomicint> native type is required.
+This type is similar to a plain native L<int|/type/int>, except it is sized such
+that CPU-provided atomic operations can be performed upon it. On a 32-bit CPU it
+will typically be 32 bits in size, and on an a 64-bit CPU it will typically be
+64 bits in size.
 
 =begin code
 # !!WRONG!! Might be non-atomic on some systems
@@ -696,23 +702,23 @@ multi-dispatch.
 
 =head1 Numeric Infectiousness
 
-Numeric "infectiousness" dictates the resultant type when two numerics of different types are
-involved in some mathematical operations. A type is said to be more infectious than the other type
-if the result is of that type rather than the type of the other operand. For example, L<Num>
-type is more infectious than an L<Int>, thus we can expect C<42e0 + 42> to produce a L<Num> as the
-result.
+Numeric "infectiousness" dictates the resultant type when two numerics of
+different types are involved in some mathematical operations. A type is said to
+be more infectious than the other type if the result is of that type rather than
+the type of the other operand. For example, L<Num> type is more infectious than
+an L<Int>, thus we can expect C<42e0 + 42> to produce a L<Num> as the result.
 
 The infectiousness is as follows, with the most infectious type listed first:
 
-=item *  Complex
+=item Complex
 
-=item * Num
+=item Num
 
-=item * FatRat
+=item FatRat
 
-=item * Rat
+=item Rat
 
-=item * Int
+=item Int
 
 =begin code
 say (2 + 2e0).^name; # Int + Num => OUTPUT: «Num␤»