Re^2: wantarray documentation in 5.8.7

What caught my attention was the "top of the file" - this is why I was referring to doing a file. A little example will serve more than a thousands words, anyway.

First script /tmp/prova1.pl uses wantarray at the top level of a file:

#!/usr/bin/perl
wantarray
        ? print("wantarray!\n")
        : defined wantarray
                ? print("wantarray defined but false\n")
                : print("wantarray undefined!\n");
wantarray
        ? qw( ciao a tutti )
        : defined wantarray && "howdy!";
[download]

When called directly, it yelds:

wantarray undefined!
[download]

but here I agree with you, we cannot rely on it. This is why I built the second script /tmp/prova2.pl:

#!/usr/bin/perl
use strict;
use warnings;
$" = ", ";

print "First: list context\n";
my @a = do '/tmp/prova1.pl';
print "array \@a = (@a)\n\n";

print "Second: void context\n";
do '/tmp/prova1.pl';

print "\nThird: scalar context\n";
my $c = do '/tmp/prova1.pl';
print "scalar \$c = $c\n";
[download]

which yelds:

First: list context
wantarray!
array @a = (ciao, a, tutti)

Second: void context
wantarray undefined!


Third: scalar context
wantarray defined but false
scalar $c = howdy!
[download]

So, the wantarray is used "at the top of the file", but it seems that wantarray is working fine. Can we rely on it? If yes, I think that the docs should be made a little clearer.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

Comment on Re^2: wantarray documentation in 5.8.7 Select or Download Code

Replies are listed 'Best First'.
Re^3: wantarray documentation in 5.8.7 by tlm (Prior) on Jul 25, 2005 at 16:17 UTC
So, the wantarray is used "at the top of the file", but it seems that wantarray is working fine. Can we rely on it? No, we can't. That's exactly what the docs are saying, unequivocally. They say that this behavior is unspecified, i.e. "don't rely on it". The fact that it appears to work in your example does not in any way contradict this. Read more... (1144 Bytes) the lowliest monk	[reply] [d/l]
Re^4: wantarray documentation in 5.8.7 by polettix (Vicar) on Jul 25, 2005 at 16:42 UTC
Maybe I'm being pedant here, luckly this answer is on the 4-th indentation. My point of view is that I would like to understand why things work this way. I can be perfectly happy with the behaviour described in the docs, but I'd like to know why and I'd like that the docs would be clearer about this issue. If the issue is about context, I'd accept it. wantarray is a function dealing with context, and if the docs would say that if you have no context, you have no use for wantarray it makes perfectly sense for me. OTOH, if the docs talk about "top of file" (whatever this means, BTW), I'm not happy. I'd like to understand what "top of file" means, and also why this "top of file" invalidates the possible usage for wantarray even when I provide a context. In other words, I'm not willing to accept this behaviour blindly only because the docs say it's so. "Why doesn't this work?" - "Because no" isn't acceptable from a super-language like Perl, and is something that is definitively under the excellent Perl documentation standards. I appreciate your examples. But they simply talk about something that makes sense: use undef only on the "basic" types you have in Perl, not on "derived" ones like slices. I understand that there could be programming issues that make this a possible point of variations for the future, and also that a line between "basic" and "derived" is a well drawn line for things like that. Imagine if you found that you could use undef on all variables, except those whose name start by "T". Wouldn't this surprise you, and deserve at least a bit of elaboration? Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply]
Re^5: wantarray documentation in 5.8.7 by Anonymous Monk on Jul 26, 2005 at 00:39 UTC
Why? There isn't always an answer to the question, the perl5-porters would know for sure.	[reply]
Re^3: wantarray documentation in 5.8.7 by themage (Friar) on Jul 25, 2005 at 14:23 UTC
wantarray, I thought, and your test would confirms it, depends on context, not scope. But then, your do as block, with the code directly inside, like this: `my @arr2=do {wantarray ? print("wantarray!\n") : defined wantarray ? print("wantarray defined but false\n") : print("wantarray undefined!\n"); wantarray ? qw( ciao a tutti ) : defined wantarray && "howdy!"; };` [download] Is always undefined, both in scalar, void or array context, and the same apply to wantarray called directly, like this: `my $sc2=wantarray ? print("wantarray!\n") && qw(ciao a tutti) : defined wantarray ? print("wantarray defined but false\n") && "howdy!" : print("wantarray undefined!\n");` [download] The way I got it working as expected were in a sub, like this: `sub wanttest { wantarray ? print("wantarray!\n") : defined wantarray ? print("wantarray defined but false\n") : print("wantarray undefined!\n"); return wantarray ? qw( ciao a tutti ) : defined wantarray && "howdy!"; } wanttest(); my $sc=wanttest(); print "Returned $sc\n\n"; my @arr=wanttest(); print "Returned @arr \n\n";` [download] Is wantarray only trustable inside subs or even there it fails to return as expected anytime? I was expecting thet the context made the trick, but after see it fail when called directly, I wasn't expecting that the do block didn't work as the do EXPR (do 'filename.pl'). TheMage http://themage.bliker.com	[reply] [d/l] [select]