Review
Richard Mateosian, IEEE, Jan/Feb 2002
http://it-enquirer.com, May 2002
Dave Cross, Linux Format, May 2002
Book Description
Product Description
If you ask Perl programmers today what book they relied on most when they were learning Perl, you'll find that an overwhelming majority will name Learning Perl--also known affectionately as "the Llama." The first edition of Learning Perl appeared in 1993 and has been a bestseller ever since. Written by two of the most prominent and active members of the Perl community, this book is the quintessential tutorial for the Perl programming language.
Perl began as a tool for Unix system administrators, used for countless small tasks throughout the workday. It has since blossomed into a full-featured programming language on practically every computing platform, and is used for web programming, database manipulation, XML processing, and (of course) system administration--all this while still remaining the perfect tool for the small daily tasks it was designed for. Perl is quick, fun, and eminently useful. Many people start using Perl because they need it, but they continue to use Perl because they love it.
The third edition of Learning Perl has not only been updated for Perl 5.6, but has also been rewritten from the ground up to reflect the needs of programmers learning Perl today. Informed by their years of success at teaching Perl as consultants, the authors have re-engineered the book to better match the pace and scope appropriate for readers trying to get started with Perl, while retaining the detailed discussion, thorough examples, and eclectic wit for which the book is famous.
This edition of the Llama includes an expanded and more gently-paced introduction to regular expressions, new exercises and solutions designed so readers can practice what they've learned while it's still fresh in their minds, and an overall reworking to bring Learning Perl into the new millennium.
Perl is a language for getting your job done. Other books may teach you to program in Perl, but this book will turn you into a Perl programmer.
From the Publisher
About the Author
Tom Phoenix has been working in the field of education since 1982. After more than thirteen years of dissections, explosions, work with interesting animals, and high-voltage sparks during his work at a science museum, he started teaching Perl classes for Stonehenge Consulting Services, where he's worked since 1996. Since then, he has traveled to many interesting locations, so you might see him soon at a Perl Mongers' meeting. When he has time, he answers questions on Usenet's comp.lang.perl.misc and comp.lang.perl.moderated newsgroups, and contributes to the development and usefulness of Perl. Besides his work with Perl, Perl hackers, and related topics, Tom spends his time on amateur cryptography and speaking Esperanto. His home is in Portland, Oregon.
Excerpted from Learning Perl by Randal L. Schwartz, Tom Phoenix. Copyright © 2001. Reprinted by permission. All rights reserved.
System and User Functions
We've already seen and used some of the builtin system functions, such as chomp, reverse, print, and so on. But, as other languages do, Perl has the ability to make subroutines, which are user-defined functions.[1] These let us recycle one chunk of code many times in one program.[2]
The name of a subroutine is another Perl identifier (letters, digits, and underscores, but can't start with a digit) with a sometimes-optional ampersand (&) in front. There's a rule about when you can omit the ampersand and when you cannot; we'll see that rule by the end of the chapter. For now, we'll just use it every time that it's not forbidden, which is always a safe rule. And we'll tell you every place where it's forbidden, of course.
That subroutine name comes from a separate namespace, so Perl won't be confused if you have a subroutine called &fred and a scalar called $fred in the same program--although there's no reason to do that under normal circumstances.
Defining a Subroutine
To define your own subroutine, use the keyword sub, the name of the subroutine (without the ampersand), then the indented[3] block of code (in curly braces) which makes up the body of the subroutine, something like this:
sub marine {
$n += 1; # Global variable $n
print "Hello, sailor number $n!\n";
}
Subroutine definitions can be anywhere in your program text, but programmers who come from a background of languages like C or Pascal like to put them at the start of the file. Others may prefer to put them at the end of the file, so that the main part of the program appears at the beginning. It's up to you. In any case, you don't normally need any kind of forward declaration.[4]
Subroutine definitions are global; without some powerful trickiness, there are no private subroutines.[5] If you have two subroutine definitions with the same name, the later one overwrites the earlier one.[6] That's generally considered bad form, or the sign of a confused maintenance programmer.
As you may have noticed in the previous example, you may use any global variables within the subroutine body. In fact, all of the variables we've seen so far are globals; that is, they are accessible from every part of your program. This horrifies linguistic purists, but the Perl development team formed an angry mob with torches and ran them out of town years ago. We'll see how to make private variables in the section "Private Variables in Subroutines" later in this chapter.
Invoking a Subroutine
Invoke a subroutine from within any expression by using the subroutine name (with the ampersand):[7]
&marine; # says Hello, sailor number 1!
&marine; # says Hello, sailor number 2!
&marine; # says Hello, sailor number 3!
&marine; # says Hello, sailor number 4!
Sometimes, we refer to the invocation as calling the subroutine.
Return Values
The subroutine is always invoked as part of an expression, even if the result of the expression isn't being used. When we invoked &marine earlier, we were calculating the value of the expression containing the invocation, but then throwing away the result.
Many times, we'll call a subroutine and actually do something with the result. This means that we'll be paying attention to the return value of the subroutine. All Perl subroutines have a return value--there's no distinction between those that return values and those that don't. Not all Perl subroutines have a useful return value, however.
Since all Perl subroutines can be called in a way that needs a return value, it'd be a bit wasteful to have to declare special syntax to "return" a particular value for the majority of the cases. So Larry made it simple. Every subroutine is chugging along, calculating values as part of its series of actions. Whatever calculation is last performed in a subroutine is automatically also the return value.
For example, let's define this subroutine:
sub sum_of_fred_and_barney {
print "Hey, you called the sum_of_fred_and_barney subroutine!\n";
$fred + $barney; # That's the return value
}
The last expression evaluated in the body of this subroutine is the sum of $fred and $barney, so the sum of $fred and $barney will be the return value. Here's that in action:
$fred = 3;
$barney = 4;
$c = &sum_of_fred_and_barney; # $c gets 7
print "\$c is $c.\n";
$d = 3 * &sum_of_fred_and_barney; # $d gets 21
print "\$d is $d.\n";
That code will produce this output:
Hey, you called the sum_of_fred_and_barney subroutine!
$c is 7.
Hey, you called the sum_of_fred_and_barney subroutine!
$d is 21.
That print statement is just a debugging aid, so that we can see that we called the subroutine. You'd take it out when the program is finished. But suppose you added another line to the end of the code, like this:
sub sum_of_fred_and_barney {
print "Hey, you called the sum_of_fred_and_barney subroutine!\n";
$fred + $barney; # That's not really the return value!
print "Hey, I'm returning a value now!\n"; # Oops!
}
In this example, the last expression evaluated is not the addition; it's the print statement. Its return value will normally be 1, meaning "printing was successful,"[8] but that's not the return value we actually wanted. So be careful when adding additional code to a subroutine to ensure that the last expression evaluated will be the desired return value.
So, what happened to the sum of $fred and $barney in that subroutine? We didn't put it anywhere, so Perl discarded it. If you had requested warnings, Perl (noticing that there's nothing useful about adding two variables and discarding the result) would likely warn you about something like "a useless use of addition in a void context." The term void context is just a fancy of saying that the answer isn't being stored in a variable or used by another function.