Like many languages, Perl provides for user-defined subroutines.
These may be located anywhere in the main program, loaded in from
other files via the C<do>, C<require>, or C<use> keywords, or
-generated on the fly using C<eval> or anonymous subroutines (closures).
+generated on the fly using C<eval> or anonymous subroutines.
You can even call a function indirectly using a variable containing
its name or a CODE reference.
}
Notice how this (unprototyped) function doesn't care whether it was
-passed real scalars or arrays. Perl sees all arugments as one big,
+passed real scalars or arrays. Perl sees all arguments as one big,
long, flat parameter list in C<@_>. This is one area where
Perl's simple argument-passing style shines. The C<upcase()>
function would work perfectly well without changing the C<upcase()>
an argument to defined() or undef(). Nor is it optional when you
want to do an indirect subroutine call with a subroutine name or
reference using the C<&$subref()> or C<&{$subref}()> constructs,
-although the C<$subref-E<gt>()> notation solves that problem.
+although the C<< $subref->() >> notation solves that problem.
See L<perlref> for more about all that.
Subroutines may be called recursively. If a subroutine is called
this with C<no strict 'vars'>.
A C<my> has both a compile-time and a run-time effect. At compile
-time, the compiler takes notice of it. The principle usefulness
+time, the compiler takes notice of it. The principal usefulness
of this is to quiet C<use strict 'vars'>, but it is also essential
for generation of closures as detailed in L<perlref>. Actual
initialization is delayed until run time, though, so it gets executed
subroutine, then it behaves like an old-fashioned subroutine. It
naturally falls out from this rule that prototypes have no influence
on subroutine references like C<\&foo> or on indirect subroutine
-calls like C<&{$subref}> or C<$subref-E<gt>()>.
+calls like C<&{$subref}> or C<< $subref->() >>.
Method calls are not influenced by prototypes either, because the
function to be called is indeterminate at compile time, since
See L<perlref/"Function Templates"> for more about references and closures.
See L<perlxs> if you'd like to learn about calling C subroutines from Perl.
-See L<perlembed> if you'd like to learn about calling PErl subroutines from C.
+See L<perlembed> if you'd like to learn about calling Perl subroutines from C.
See L<perlmod> to learn about bundling up your functions in separate files.
See L<perlmodlib> to learn what library modules come standard on your system.
See L<perltoot> to learn how to make object method calls.