On Tue, Jul 26, 2005 at 06:29:57PM +0200, Flavio Poletti wrote: > The obscure passage is the following: > > wantarray()'s result is unspecified in the top level of a file, > in a BEGIN , CHECK , INIT or END block, or in a DESTROY method. > > All make sense to me except "top level of a file", which is obscure IMHO. > Could it be explained more in depth? My very issue regards the use of "do" > on a file: it currently seems to support wantarray correctly even "in the > top level of a file" (example at > http://www.perlmonks.org/?node_id=477801), but I'd like to know if this > still falls in the "unspecified behaviour" warning and, if yes, why.
> Unfortunately, my Perl Powers are too weak for me to propose something > 100% correct and clear. But I want to be proactive and try to propose to > change "file" into "program": > > wantarray()'s result is unspecified in the top level of a program, > in a BEGIN , CHECK , INIT or END block, or in a DESTROY method. I find that more ambiguous. To me, programs can span more than one file, so the top level to me would mean just the perl file passed as an argument to the interpreter. Would a clarification work? In effect, wantarray is only specified within subroutines/methods defined using the C<sub> keyword, with the exception of implicit calls to DESTROY. I was going to say "places you can call and get a value returned from", but IIRC you can return a value from a file, which C<do> will return you. So is "wantarray's value is only specified within a subroutine or method which was called directly by other perl code" true? (And then list the exceptions as the interpreter's implicit calls to BEGIN ... blocks, DESTROY methods, and any other file loaded by do/require/use) Is the current documentation actually *wrong*. In that the unspecified-ness propagates? ie the documentation says that this wantarray is specified: $ perl -lwe 'sub a {print "=", wantarray}; BEGIN {a}' = But I think that actually it's not. > Note that you can still get a context in the top level of a file > when you use C<do 'file.pl';>. In this case, in fact, the code inside > I<file.pl> is provided a context according to the call to C<do>: > > my @a = do 'file.pl'; # array context provided > my $s = do 'file.pl'; # scalar context provided > do 'file.pl'; # void or "external" context provided > > Dealing with context, these calls to C<do 'file.pl'> are equivalent > to sub calls; the last line, for example, could "inherit" the context > when called as the final statement of a sub or of a file. I think that the documentation was attempting to say that we specifically don't guarantee that this context will remain the same in future perl versions. So don't rely on it. Nicholas Clark