I've noticed interesting thing. The code
sub test{ return qw(a b c); }
my $n = test;
print $n, "\n";
produces "c" instead of 3.
I have perl 5.8.8.
According to perldoc perlsub
The Perl model for function call and return values is simple: all
functions are passed as parameters one single flat list of
scalars, and all functions likewise return to their caller one
single flat list of scalars.
In this case it looks like instead of making an array, perl does
my $n = ('a', 'b', 'c');
which is completely different thing. Is this a bug, or documentation has
to be updated? :)
--
Minds, like parachutes, function best when open
>On Thu, May 28, 2009 at 4:22 PM, Bruce Van Allen <b...@cruzio.com> wrote:
>>On 5/28/09 at 3:13 AM, avo...@mail.ru (Andrei Voropaev) wrote:
>>
>>> According to perldoc perlsub
>>> The Perl model for function call and return values is simple: all
>>> functions are passed as parameters one single flat list of
>>> scalars, and all functions likewise return to their caller one
>>> single flat list of scalars.
>>>
>>> In this case it looks like instead of making an array, perl does
>>>
>>> my $n = ('a', 'b', 'c');
>>>
>>> which is completely different thing. Is this a bug, or documentation has
>>> to be updated? :)
>>>
>>
>>That's the expected behavior. The return value is 'c' because qw(a b c)
>>yields a list of quoted words -- ('a', 'b', 'c') -- not an array.
>>
>>In the subroutine above, that list is processed and its final value
>>returned: 'c'.
>
>Well. I've figured as much myself. But the documentation snippet I've quoted
>above in plain words states, that the functions return "one single flat list
>of scalars". And further down "Any arrays or hashes in these call and return
>lists will collapse, losing their identities".
>
>So the behavior I see now, does not match the description. In reality, perl
>first checks the context and based on this returns result of processing of the
>value being returned. The description implies, that all returned values are
>placed into array (arrays are also placed there) and then this array is
>returned into context that the user expects.
>
>I guess, if current behavior is intentional, then the documentation has to be
>adjusted accordingly. Otherwise there's confusion. Personally I prefer the way
>described in documentation. This description is simple :)
>
>What do you think?
I agree that the doc language you quoted could be misunderstood.
I think I've mostly paid attention to the significance of that
doc section as it relates to the subroutine's *input* args,
rather than the output.
However, just to be clear: a "single flat list of scalars" is
not the same thing as an array. The example code you posted
shows this.
$n = ('a', 'b', 'c');
# $n eq 'c'
@a = ('a', 'b', 'c');
$n = @a;
# $n == 3
[Note: I prefer to keep list correspondence on the list.]
- Bruce
_bruce__van_allen__santa_cruz_ca_
: I've noticed interesting thing. The code
:
: sub test{ return qw(a b c); }
: my $n = test;
: print $n, "\n";
:
: produces "c" instead of 3. [...]
The perlop manpage's description of qw/STRING/:
Evaluates to a list of the words extracted out of
STRING, using embedded whitespace as the word
delimiters. It can be understood as being roughly
equivalent to:
split(' ', q/STRING/);
the differences being that it generates a real list
at compile time, and IN SCALAR CONTEXT IT RETURNS
THE LAST ELEMENT IN THE LIST.
Emphasis added.
By assigning the result of test to $n, you're calling it in
scalar context. If you want the whole mamma-jamma, call it in
list context:
$ perl -le 'sub test{return qw(a b c)} @a = test; print @a'
abc
I assigned to an array to emphasize that the call is in list
context, but print already provides it:
$ perl -le 'sub test{return qw(a b c)} print test'
abc
Forcing scalar context shows the behavior you're seeing:
$ perl -le 'sub test{return qw(a b c)} print scalar test'
c
Hope this helps,
Greg
--
Private enterprise creates; government destroys. That is the great
economic lesson of our times and all times.
-- Lew Rockwell
That's the expected behavior. The return value is 'c' because
qw(a b c) yields a list of quoted words -- ('a', 'b', 'c') --
not an array.
In the subroutine above, that list is processed and its final
value returned: 'c'.
The processing is done by the comma, in its capacity as a binary
operator; it evaluates the argument to its left, then the
argument to its right, and returns the value from the argument
to its right. Processing then moves down the list (left to
right), and continues to the end. The last right-side argument
is 'c' which evaluates to itself.
You would get the result of '3' if the returned variable was an
array; as you expected, arrays return their length in scalar
context, which in this case comes from assigning the subroutine
output to a scalar variable, $n.
Try this:
sub test{
my @a = qw(a b c);
return @a;
}
my $n = test;
print $n, "\n";
#3
my @a = test;
print @a, "\n";
#abc
HTH
- Bruce
_bruce__van_allen__santa_cruz_ca_
Your're usinq qw in scalar context. Might not give the best results. According to perlop:
qw/STRING/
Returns a list of the words extracted out of STRING, using embedded whitespace as the word delimiters. It is exactly equivalent to
split(' ', q/STRING/);
This equivalency means that if used in scalar context, you'll get split's (unfortunate) scalar context behavior, complete with mysterious warnings.
Sébastien
> -----Message d'origine-----
> De :
> clpm-bounces-sebastien.nadeau=bibl.ul...@lists.eyrie.org
> [mailto:clpm-bounces-sebastien.nadeau=bibl.ul...@lists.eyr
ie.org] De la part de Andrei Voropaev
> Envoyé : 28 mai 2009 06:14
> À : cl...@lists.eyrie.org
> Objet : returning list from function
Yes, I should have been more careful with the terms I use. I understand
the difference between array and list. Basically this whole issue came
up because I've blindly believed that the functions return arrays.
Now I've started to dig into docs to understand what exactly is
happening and got even more confused :)
The perlsub states "Any arrays or hashes in these call and return lists
will collapse, losing their identities". The perldata also states
********
LISTs do automatic interpolation of sublists. That is, when a LIST is
evaluated, each element of the list is evaluated in list context, and
the resulting list value is interpo- lated into LIST just as if each
individual element were a member of LIST. Thus arrays and hashes lose
their identity in a LIST--the list
********
Now I take the code
my @ar = qw(k l m);
my $len = ('a', 'b', @ar);
and get $len == 3.
Though theoretically this @ar should be interpolated into LIST "as if each
individual element were a member of LIST". But the example above shows
that the @ar is not interpolated into the surrounding list and keeps
it's identity. So instead of value 'm' I get value 3.
The documentation definetely should more clear on how exactly LISTs work
: Yes, I should have been more careful with the terms I use. I
: understand the difference between array and list. Basically this
: whole issue came up because I've blindly believed that the functions
: return arrays.
Do you now have a better understanding of how context affects what
functions return?
: Now I've started to dig into docs to understand what exactly is
: happening and got even more confused :)
:
: The perlsub states "Any arrays or hashes in these call and return lists
: will collapse, losing their identities". The perldata also states
:
: ********
: LISTs do automatic interpolation of sublists. That is, when a LIST is
: evaluated, each element of the list is evaluated in list context, and
: the resulting list value is interpolated into LIST just as if each
: individual element were a member of LIST. Thus arrays and hashes lose
: their identity in a LIST...
: ********
A few paragraphs about the cited passage, you'll find
In a context not requiring a list value, the value of
what appears to be a list literal is simply the value
of the final element, as with the C comma operator.
: Now I take the code
:
: my @ar = qw(k l m);
:
: my $len = ('a', 'b', @ar);
:
: and get $len == 3.
Right: in scalar context it's equivalent to $len = @ar;
: [...]
Hope this helps,
Greg
--
If the Constitution is to be construed to mean what the majority at any
given period in history wish the Constitution to mean, why a written
Constitution?
-- Frank J. Hogan