3.2.2.1 Efficient parameter passing

Aliases happen to be quite a bit faster than references, because they don't need to do any dereferencing. Consider

$a = 10;
*b = *a ; $b++ ;  # 1. Increment $a indirectly through the typeglob
$r = \$a; $$r++;  # 2. Increment $a indirectly through the reference

Case 1 is around one and a half times faster than case 2 on my PC.

The example code below uses typeglobs to efficiently pass an array by reference to a subroutine, DoubleEachEntry , which doubles each element of the array:

@array = (10,20);
DoubleEachEntry(
*array
); # @array and @copy are identical.
print "@array \n"; # prints 20 40

sub DoubleEachEntry {
    # $_[0] contains *array
    local 
*copy
 = shift;  # Create a local alias
    foreach $element (@copy) {
        $element *= 2;
    }
}

Note that only one parameter is passed to the subroutine. The typeglob *copy springs into existence when it is first encountered, but because it didn't exist prior to the local statement, it and the corresponding entry in the symbol table are removed at the end of the block.

Incidentally, the code also takes advantage of the fact that the foreach statement internally aliases each successive element of @copy to $element , so modifying $element affects the elements of @copy (and therefore @array as well).

You cannot use a lexically scoped array as a parameter to DoubleEachEntry , because lexical variables don't have typeglobs associated with them. The restriction is easily circumvented, however. Typeglobs and references are strangely equivalent, as it turns out. You can pass in an ordinary reference to a subroutine expecting a typeglob, and it'll work well. (We'll have a little more to say about this in the section "Typeglobs and References .") That is, you can pass lexically scoped arrays to DoubleEachEntry like this:

my @array  = (1, 2, 3);
DoubleEachEntry(\@array); # Instead of *array, which wouldn't work

3.2.2.2 Aliasing on command lines

I often embed the Perl interpreter in my C/C++ programs to provide a powerful shell-like frontend. While I like to use long and descriptive subroutine names in Perl scripts, it is painful to keep typing them on the frontend's prompt. Aliases are very useful here:

sub a_long_drawn_out_sub_name {
   print "A sub by any other name is still a sub \n";
}
*f = *a_long_drawn_out_sub_name; # create an alias 

Now typing f() on the command line is the same as calling the original subroutine but much easier on the carpals!

3.2.2.3 Friendly predefined variables with aliases

Consider the opposite case. Perl has a number of cryptic built-in variables such as $! , $/ , and $@ , and many people would much rather work with longer descriptive names. The module English.pm in the standard Perl library comes to the rescue; it provides nice big, long aliased names, such as $ERRNO , $INPUT_RECORD_SEPARATOR , and $EVAL_ERROR (respectively). Try this:

use English;    # Import the module file called English.pm
# Try deleting a non-existent file
unlink ('/tmp/foo');
if (
$ERRNO
)  {  # Use $ERRNO instead of $!
    print $ERRNO, "\n"; # Prints "No such file or directory"
}

(We'll cover packages and the use statement in Chapter 6 .) I think these well-known names should have been in there from the very beginning, instead of having to memorize funny-looking variables and an accompanying list of mnemonics. Some argue that you can use the same scheme for other languages (" use Dutch; "), but considering that the other system calls are in English anyway, I think that there's no point providing specific aliases for a small subset of the things you have to remember.