-Now you cannot alter $PI, which is probably a good thing all in all.
-
-=head2 Package Constructors and Destructors
-
-There are two special subroutine definitions that function as package
-constructors and destructors. These are the C<BEGIN> and C<END>
-routines. The C<sub> is optional for these routines.
-
-A C<BEGIN> subroutine is executed as soon as possible, that is, the
-moment it is completely defined, even before the rest of the containing
-file is parsed. You may have multiple C<BEGIN> blocks within a
-file--they will execute in order of definition. Because a C<BEGIN>
-block executes immediately, it can pull in definitions of subroutines
-and such from other files in time to be visible to the rest of the
-file.
-
-An C<END> subroutine is executed as late as possible, that is, when the
-interpreter is being exited, even if it is exiting as a result of a
-die() function. (But not if it's is being blown out of the water by a
-signal--you have to trap that yourself (if you can).) You may have
-multiple C<END> blocks within a file--they will execute in reverse
-order of definition; that is: last in, first out (LIFO).
-
-Note that when you use the B<-n> and B<-p> switches to Perl, C<BEGIN>
-and C<END> work just as they do in B<awk>, as a degenerate case.
-
-=head2 Perl Classes
-
-There is no special class syntax in Perl, but a package may function
-as a class if it provides subroutines that function as methods. Such a
-package may also derive some of its methods from another class package
-by listing the other package name in its @ISA array.
-
-For more on this, see L<perlobj>.
-
-=head2 Perl Modules
-
-A module is just a package that is defined in a library file of
-the same name, and is designed to be reusable. It may do this by
-providing a mechanism for exporting some of its symbols into the symbol
-table of any package using it. Or it may function as a class
-definition and make its semantics available implicitly through method
-calls on the class and its objects, without explicit exportation of any
-symbols. Or it can do a little of both.
-
-For example, to start a normal module called Fred, create
-a file called Fred.pm and put this at the start of it:
-
- package Fred;
- require Exporter;
- @ISA = qw(Exporter);
- @EXPORT = qw(func1 func2);
- @EXPORT_OK = qw($sally @listabob %harry func3);
-
-Then go on to declare and use your variables in functions
-without any qualifications.
-See L<Exporter> and the I<Perl Modules File> for details on
-mechanics and style issues in module creation.
-
-Perl modules are included into your program by saying
-
- use Module;
-
-or
-
- use Module LIST;
-
-This is exactly equivalent to
-
- BEGIN { require "Module.pm"; import Module; }
-
-or
-
- BEGIN { require "Module.pm"; import Module LIST; }
-
-As a special case
-
- use Module ();
-
-is exactly equivalent to
-
- BEGIN { require "Module.pm"; }
-
-All Perl module files have the extension F<.pm>. C<use> assumes this so
-that you don't have to spell out "F<Module.pm>" in quotes. This also
-helps to differentiate new modules from old F<.pl> and F<.ph> files.
-Module names are also capitalized unless they're functioning as pragmas,
-"Pragmas" are in effect compiler directives, and are sometimes called
-"pragmatic modules" (or even "pragmata" if you're a classicist).
-
-Because the C<use> statement implies a C<BEGIN> block, the importation
-of semantics happens at the moment the C<use> statement is compiled,
-before the rest of the file is compiled. This is how it is able
-to function as a pragma mechanism, and also how modules are able to
-declare subroutines that are then visible as list operators for
-the rest of the current file. This will not work if you use C<require>
-instead of C<use>. With require you can get into this problem:
-
- require Cwd; # make Cwd:: accessible
- $here = Cwd::getcwd();
-
- use Cwd; # import names from Cwd::
- $here = getcwd();
-
- require Cwd; # make Cwd:: accessible
- $here = getcwd(); # oops! no main::getcwd()
-
-In general C<use Module ();> is recommended over C<require Module;>.
-
-Perl packages may be nested inside other package names, so we can have
-package names containing C<::>. But if we used that package name
-directly as a filename it would makes for unwieldy or impossible
-filenames on some systems. Therefore, if a module's name is, say,
-C<Text::Soundex>, then its definition is actually found in the library
-file F<Text/Soundex.pm>.
-
-Perl modules always have a F<.pm> file, but there may also be dynamically
-linked executables or autoloaded subroutine definitions associated with
-the module. If so, these will be entirely transparent to the user of
-the module. It is the responsibility of the F<.pm> file to load (or
-arrange to autoload) any additional functionality. The POSIX module
-happens to do both dynamic loading and autoloading, but the user can
-just say C<use POSIX> to get it all.
-
-For more information on writing extension modules, see L<perlxs>
-and L<perlguts>.
-
-=head1 NOTE
-
-Perl does not enforce private and public parts of its modules as you may
-have been used to in other languages like C++, Ada, or Modula-17. Perl
-doesn't have an infatuation with enforced privacy. It would prefer
-that you stayed out of its living room because you weren't invited, not
-because it has a shotgun.
-
-The module and its user have a contract, part of which is common law,
-and part of which is "written". Part of the common law contract is
-that a module doesn't pollute any namespace it wasn't asked to. The
-written contract for the module (AKA documentation) may make other
-provisions. But then you know when you C<use RedefineTheWorld> that
-you're redefining the world and willing to take the consequences.
-
-=head1 THE PERL MODULE LIBRARY
-
-A number of modules are included the the Perl distribution. These are
-described below, and all end in F<.pm>. You may also discover files in
-the library directory that end in either F<.pl> or F<.ph>. These are old
-libraries supplied so that old programs that use them still run. The
-F<.pl> files will all eventually be converted into standard modules, and
-the F<.ph> files made by B<h2ph> will probably end up as extension modules
-made by B<h2xs>. (Some F<.ph> values may already be available through the
-POSIX module.) The B<pl2pm> file in the distribution may help in your
-conversion, but it's just a mechanical process, so is far from bullet proof.
-
-=head2 Pragmatic Modules
-
-They work somewhat like pragmas in that they tend to affect the compilation of
-your program, and thus will usually only work well when used within a
-C<use>, or C<no>. These are locally scoped, so an inner BLOCK
-may countermand any of these by saying
-
- no integer;
- no strict 'refs';
-
-which lasts until the end of that BLOCK.
-
-The following programs are defined (and have their own documentation).
-
-=over 12
-
-=item diagnostics
-
-Pragma to produce enhanced diagnostics
-
-=item integer
-
-Pragma to compute arithmetic in integer instead of double
-
-=item less
-
-Pragma to request less of something from the compiler
-
-=item overload
-
-Pragma for overloading operators
-
-=item sigtrap
-
-Pragma to enable stack backtrace on unexpected signals
-
-=item strict
-
-Pragma to restrict unsafe constructs
-
-=item subs
-
-Pragma to predeclare sub names
-
-=back
-
-=head2 Standard Modules
-
-Standard, bundled modules are all expected to behave in a well-defined
-manner with respect to namespace pollution because they use the
-Exporter module. See their own documentation for details.
-
-=over 12
-
-=item AnyDBM_File
-
-provide framework for multiple DBMs
-
-=item AutoLoader
-
-load functions only on demand
-
-=item AutoSplit
-
-split a package for autoloading
-
-=item Benchmark
-
-benchmark running times of code
-
-=item Carp
-
-warn of errors (from perspective of caller)
-
-=item Config
-
-access Perl configuration option
-
-=item Cwd
-
-get pathname of current working directory
-
-=item DB_File
-
-Perl access to Berkeley DB
-
-=item Devel::SelfStubber
-
-generate stubs for a SelfLoading module
-
-=item DynaLoader
-
-Dynamically load C libraries into Perl code
-
-=item English
-
-use nice English (or awk) names for ugly punctuation variables
-
-=item Env
-
-perl module that imports environment variables
-
-=item Exporter
-
-provide inport/export controls for Perl modules
-
-=item ExtUtils::Liblist
-
-determine libraries to use and how to use them
-
-=item ExtUtils::MakeMaker
-
-create an extension Makefile
-
-=item ExtUtils::Manifest
-
-utilities to write and check a MANIFEST file
-
-=item ExtUtils::Mkbootstrap
-
-make a bootstrap file for use by DynaLoader
-
-=item ExtUtils::Miniperl
-
-!!!GOOD QUESTION!!!
-
-=item Fcntl
-
-load the C Fcntl.h defines
-
-=item File::Basename
-
-parse file specifications