correct some typos and spellings

doc/Language/nativecall.pod

@@ -17,7 +17,7 @@ The simplest imaginable use of NativeCall would look something like this:
 The first line imports various traits and types. The next line looks like
 a relatively ordinary Perl 6 sub declaration - with a twist. We use the
 "native" trait in order to specify that the sub is actually defined in a
-native library. The platform-specific extension (e.g. .so or .dll) will be
+native library. The platform-specific extension (e.g., '.so' or '.dll') will be
 added for you.
 
 The first time you call "some_argless_function", the "libsomething" will be
@@ -79,7 +79,7 @@ likely grow with time).
     size_t         (size_t in C)
 
 Don't use Perl 6 native types like C<int> or C<num>, as they don't have to
-correspond to the local C equivalent (e.g. Perl 6's C<int> can be 8 bytes but
+correspond to the local C equivalent (e.g., Perl 6's C<int> can be 8 bytes but
 C's C<int> is only 4 bytes).
 
 Note that the lack of a C<returns> trait is used to indicate void return type.
@@ -178,7 +178,7 @@ Once again, type objects are used to represent nulls.
 =head1 Function Pointers
 
 C libraries can expose pointers to C functions as return values of functions and as
-members of Structures like e.g. structs and unions.
+members of Structures like, e.g., structs and unions.
 
 Example of invoking a function pointer "$fptr" returned by a function "f", using a
 signature defining the desired function parameters and return value:
@@ -194,7 +194,7 @@ signature defining the desired function parameters and return value:
 
 NativeCall has some support for arrays. It is constrained to work with machine-size
 integers, doubles and strings, sized numeric types, arrays of pointers, arrays of
-structs and arrays of arrays.
+structs, and arrays of arrays.
 
 Perl 6 arrays, which support amongst other things laziness, are laid out in memory
 in a radically different way to C arrays. Therefore, the NativeCall library offers
@@ -226,7 +226,7 @@ use C<$> all the way when using NativeCall. :-)
 Getting return values for arrays works out just the same.
 
 Some library APIs may take an array as a buffer that will be populated by the
-C function and, for, instance, return the actual number of items populated:
+C function and, for instance, return the actual number of items populated:
 
     sub get_n_ints(CArray[int32], int32) returns int32 is native('ints') { * }
 
@@ -330,8 +330,8 @@ instead:
 
 TBD more
 
-You can type your C<Pointer> with passing the type as parameter. It works with native type
-but also C<CArray> and C<CStruct> defined type. NativeCall will not implicitly alloc the memory for it
+You can type your C<Pointer> by passing the type as a parameter. It works with the native type
+but also with C<CArray> and C<CStruct> defined types. NativeCall will not implicitly alloc the memory for it
 even when calling new on them.
 It's mostly useful in the case of a C routine returning a pointer, or if it's a pointer
 embedded in a C<CStruct>.
@@ -379,10 +379,10 @@ The C<native> trait accepts the library name or the full path.
     sub mysql_affectied_rows( .. ) returns int32 is native(LIBMYSQL);
     sub bar is native(LIBFOO);
 
-You can also put incomplete path like './foo', NativeCall will automaticly put
+You can also put an incomplete path like './foo', NativeCall will automatically put
 the right extension according to the plateform specification.
 
-BE CAREFUL: the C<native> trait and C<constant> are evalued at compile time. Don't write a constant
+BE CAREFUL: the C<native> trait and C<constant> are evaluated at compile time. Don't write a constant
 that depend on dynamic variable like:
 
     constant LIBMYSQL = %*ENV<P6LIB_MYSQLCLIENT> || 'mysqlclient';
@@ -393,12 +393,12 @@ keep the value it get evaluated when the module get precompiled.
 =head2 ABI/API Version
 
 If you write C<native('foo')> NativeCall will search libfoo.so under Unix like system (libfoo.dynlib on Os X, foo.dll on win32).
-In most modern system it will requiere you or the user of your module to install
-the develepment package because it's recommanded to always provide an API/ABI version to a
+In most modern system it will require you or the user of your module to install
+the develepment package because it's recommended to always provide an API/ABI version to a
 shared library, so libfoo.so ends often being a symbolic link provided only by a devel package.
 
-To avoid that, the C<native> trait allow you to specify the API/ABI version. It can be a full
-version or just a part of it (Try to stick to Major version, some BSD does not care for minor)
+To avoid that, the C<native> trait allows you to specify the API/ABI version. It can be a full
+version or just a part of it. (Try to stick to Major version, some BSD code does not care for Minor.)
 
     sub foo is native('foo', v1); # Will try to load libfoo.so.1
     sub foo is native('foo', v1.2.3); # Will try to load libfoo.so.1.2.3