 | Chapter 2: Bits and Pieces |  |
Until now we've seen several terms that can produce scalar values. Before we can discuss terms further, though, we must come to terms with the notion of context.
Every operation[16] that you invoke in a Perl script is evaluated in a specific context, and how that operation behaves may depend on the requirements of that context. There are two major contexts: scalar and list. For example, assignment to a scalar variable, or to a scalar element of an array or hash, evaluates the righthand side in a scalar context:
$x = funkshun(); # scalar context
$x[1] = funkshun(); # scalar context
$x{"ray"} = funkshun(); # scalar context
But assignment to an array or a hash, or to a slice of either, evaluates the
righthand side in a list context, even if the slice picks out
only one element:
@x = funkshun(); # list context
@x[1] = funkshun(); # list context
@x{"ray"} = funkshun(); # list context
%x = funkshun(); # list context
Assignment to a list of scalars also provides a list context to the
righthand side, even if there's only one element in the list:
These rules do not change at all when you declare a variable by modifying the term with my or our, so we have:($x,$y,$z) = funkshun(); # list context ($x) = funkshun(); # list context
my $x = funkshun(); # scalar context my @x = funkshun(); # list context my %x = funkshun(); # list context my ($x) = funkshun(); # list context
[16] Here we use the term "operation" loosely to mean either an operator or a term. The two concepts fuzz into each other when you start talking about functions that parse like terms but look like unary operators.
You will be miserable until you learn the difference between scalar and list context, because certain operators (such as our mythical funkshun() function above) know which context they are in, and return a list in contexts wanting a list but a scalar value in contexts wanting a scalar. (If this is true of an operation, it will be mentioned in the documentation for that operation.) In computer lingo, the operations are overloaded on their return type. But it's a very simple kind of overloading, based only on the distinction between singular and plural values, and nothing else.
If some operators respond to context, then obviously something around them has to supply the context. We've shown that assignment can supply a context to its right operand, but that's not terribly surprising, since all operators supply some kind of context to each of their operands. What you really want to know is which operators supply which context to their operands. As it happens, you can easily tell which ones supply a list context because they all have LIST in their syntactic descriptions. Everything else supplies a scalar context. Generally, it's quite intuitive.[17] If necessary, you can force a scalar context onto an argument in the middle of a LIST by using the scalar pseudofunction. Perl provides no way to force a list context in a scalar context, because anywhere you would want a list context it's already provided by the LIST of some controlling function.
[17] Note, however, that the list context of a LIST can propagate down through subroutine calls, so it's not always obvious from inspection whether a given statement is going to be evaluated in a scalar or list context. The program can find out its context within a subroutine by using the wantarray function.
Scalar context can be further classified into string context, numeric context, and don't-care context. Unlike the scalar versus list distinction we just made, operations never know or care which scalar context they're in. They simply return whatever kind of scalar value they want to and let Perl translate numbers to strings in string context, and strings to numbers in numeric context. Some scalar contexts don't care whether a string or a number or a reference is returned, so no conversion will happen. This happens, for example, when you are assigning the value to another variable. The new variable just takes on the same subtype as the old value.
Another special don't-care scalar context is called Boolean context. Boolean context is simply any place where an expression is being evaluated to see whether it's true or false. When we say "true" and "false" in this book, we mean the technical definition that Perl uses: a scalar value is true if it is not the null string "" or the number 0 (or its string equivalent, "0"). A reference is always true because it represents an address which is never 0. An undefined value (often called undef) is always false because it looks like either "" or 0, depending on whether you treat it as a string or a number. (List values have no Boolean value because list values are never produced in a scalar context!)
Because Boolean context is a don't-care context, it never causes any scalar conversions to happen, though of course the scalar context itself is imposed on any operand that cares. And for many operands that care, the scalar they produce in scalar context represents a reasonable Boolean value. That is, many operators that would produce a list in list context can be used for a true/false test in Boolean context. For instance, in list context such as that provided by the unlink operator, an array name produces the list of its values:
But if you use the array in a conditional (that is, in a Boolean context), the array knows it's in a scalar context and returns the number of elements in the array, which conveniently is true as long as there are any elements left. So supposing you wanted to get warnings on each file that wasn't deleted properly, you might write a loop like this:unlink @files; # Delete all files, ignoring errors.
while (@files) {
my $file = shift @files;
unlink $file or warn "Can't delete $file: $!\n";
}
Here @files is evaluated in the Boolean context supplied by the
while statement, so Perl evaluates the array itself to see whether
it's a "true array" or a "false array". It's a true array as long
as there are filenames in it, but it becomes a false array as soon as
the last filename is shifted out. Note that what we earlier said
still holds. Despite the fact that an array contains (and can
produce) a list value, we are not evaluating a list value in scalar
context. We are telling the array it's a scalar and asking what
it thinks of itself.
Do not be tempted to use defined @files for this. It doesn't work because the defined function is asking whether a scalar is equal to undef, but an array is not a scalar. The simple Boolean test suffices.
Another peculiar kind of scalar context is the void context. This context not only doesn't care what the return value's type is, it doesn't even want a return value. From the standpoint of how functions work, it's no different from an ordinary scalar context. But if you have warnings enabled, the Perl compiler will warn you if you use an expression with no side effects in a place that doesn't want a value, such as in a statement that doesn't return a value. For example, if you use a string as a statement:
you may get a warning like this:"Camel Lot";
Useless use of a constant in void context in myprog line 123;
We mentioned earlier that double-quoted literal strings do backslash interpretation and variable interpolation, but that the interpolative context (often called "double-quote context" because nobody can pronounce "interpolative") applies to more than just double-quoted strings. Some other double-quotish constructs are the generalized backtick operator qx//, the pattern match operator m//, the substitution operator s///, and the quote regex operator, qr//. The substitution operator does interpolation on its left side before doing a pattern match, and then does interpolation on its right side each time the left side matches.
The interpolative context only happens inside quotes, or things that work like quotes, so perhaps it's not fair to call it a context in the same sense as scalar and list contexts. (Then again, maybe it is.)
|  | |
| 2.6. Scalar Values |  | 2.8. List Values and Arrays |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
HIVE: All information for read only. Please respect copyright! |
