Re: wantarray() description in perlfunc as of v5.8.7
Can we put this in the documentation? I.e. can we state that the user can rely on wantarray work not only in subs (with the limitations pointed out by Nicholas and tentatively written in my previous e-mail) but also in eval and do 'file' calls? Of course, if this part of the sources is likely to have variations in the future, we should probably stick to the sub-only description, leaving other scenarios as unspecified even if they work today. OTOH, if the implementation of wantarray isn't likely to change, we could probably be more detailed about when wantarray will work, and when not. Of course, if the latter is the winning choice, I volunteer to write a draft description; otherwise I'd propose the text in my previous e-mail. Best regards, Flavio Poletti. On Tue, Jul 26, 2005 at 11:35:46PM +0200, Abigail wrote: On Tue, Jul 26, 2005 at 05:37:39PM +0100, Nicholas Clark wrote: So is wantarray's value is only specified within a subroutine or method which was called directly by other perl code true? No. $ perl -wle 'print eval wantarray' 1 $ No subroutine, no method. A quick look at the src shows that it scans back through the current context stack for an eval, sub or format. From this perspective, a require or do file is an eval. If it it fails to find one, it returns undef. It doesn't scan previous context stacks, so it wont backtrack through magic, tie, overload etc. -- The perl5 internals are a complete mess. It's like Jenga - to get the perl5 tower taller and do something new you select a block somewhere in the middle, with trepidation pull it out slowly, and then carefully balance it somewhere new, hoping the whole edifice won't collapse as a result. - Nicholas Clark, based on an original by Simon Cozens.
Re: wantarray() description in perlfunc as of v5.8.7
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 Csub 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 Cdo 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 Cdo 'file.pl';. In this case, in fact, the code inside
Ifile.pl is provided a context according to the call to Cdo:
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 Cdo '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
Re: wantarray() description in perlfunc as of v5.8.7
Aaah, things are clearer now - the sub constraint seems robust and
rational to me (see also http://www.perlmonks.org/?node_id=477891).
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.
So I think that we can safely say that it's not, even if it could actually
be. The whole point of unspecifiedness is that you should not rely on such
a behaviour, so to be on the safe side I would say that wantarray is not
specified in this scenario.
This is what I tried to put into my proposal below:
--- CUT HERE ---
wantarray()'s result is only specified within subroutines/methods
defined using the Csub keyword, with the only exception of
implicit calls to DESTROY. Thus, wantarray is unspecified
in a BEGIN, CHECK, INIT and END block (they're not regular subs) and
when using Cdo in whatever form (also not a sub, although it
returns the value of the last statement).
Note that unspecified means that it could work as you would
expect/desire now, but this is not guaranteed for the future
and you should not rely on it.
Also note that wantarray()'s result is unspecified when you call
your subroutine from unspecified contexts. So, if you have this:
sub foo {
return qw( Hello world! ) if wantarray;
return 'Howdy!' if defined wantarray;
die CONSIDER ME!!!;
}
wantarray() is generally specified, except when you call the sub like
this:
BEGIN { foo }
Being the last statement in the block, foo inherits the calling
context from BEGIN, which is unspecified as said before.
--- CUT HERE ---
Best regards,
Flavio Poletti.
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 05:37:39PM +0100, Nicholas Clark wrote: So is wantarray's value is only specified within a subroutine or method which was called directly by other perl code true? No. $ perl -wle 'print eval wantarray' 1 $ No subroutine, no method. Abigail pgpAidcPDvgz1.pgp Description: PGP signature
Re: wantarray() description in perlfunc as of v5.8.7
On Jul 26, 2005, at 5:35 PM, Abigail wrote:
On Tue, Jul 26, 2005 at 05:37:39PM +0100, Nicholas Clark wrote:
So is wantarray's value is only specified within a subroutine or
method
which was called directly by other perl code true?
No.
$ perl -wle 'print eval wantarray'
1
$
No subroutine, no method.
The eval is still a block scope from which one can return, so wantarray
indicates the context provided to the eval block, not to the -e script,
and print provides it a list context.
Compare:
$ perl -wle 'print eval { eval { wantarray } }'
1
$ perl -wle 'print eval { eval { wantarray }; }'
Useless use of wantarray in void context at -e line 1.
$
It would be helpful to have a term which means 'block from which one
can return', i.e. a sub or eval. Suppose we use the word 'frame'.
Then I'd propose the statement above except with 'frame' instead of
'subroutine or method'.
Josh
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 05:59:20PM -0400, Joshua Juran wrote:
On Jul 26, 2005, at 5:35 PM, Abigail wrote:
On Tue, Jul 26, 2005 at 05:37:39PM +0100, Nicholas Clark wrote:
So is wantarray's value is only specified within a subroutine or
method
which was called directly by other perl code true?
No.
$ perl -wle 'print eval wantarray'
1
$
No subroutine, no method.
The eval is still a block scope from which one can return, so wantarray
indicates the context provided to the eval block, not to the -e script,
and print provides it a list context.
Compare:
$ perl -wle 'print eval { eval { wantarray } }'
1
$ perl -wle 'print eval { eval { wantarray }; }'
Useless use of wantarray in void context at -e line 1.
$
It would be helpful to have a term which means 'block from which one
can return', i.e. a sub or eval. Suppose we use the word 'frame'.
Then I'd propose the statement above except with 'frame' instead of
'subroutine or method'.
This whole exercise started because people found the current documentation
unclear. I don't think that introducing the concept frame is going to
make the documentation any more clear. Perhaps less.
Abigail
pgpJTOe5zsMKq.pgp
Description: PGP signature
Re: wantarray() description in perlfunc as of v5.8.7
On Wed, Jul 27, 2005 at 12:07:57AM +0200, Abigail wrote: It would be helpful to have a term which means 'block from which one can return', i.e. a sub or eval. Suppose we use the word 'frame'. Then I'd propose the statement above except with 'frame' instead of 'subroutine or method'. This whole exercise started because people found the current documentation unclear. I don't think that introducing the concept frame is going to make the documentation any more clear. Perhaps less. If there are several places in the documentation where we refer to this odd sort of lexical/subroutine/eval... thing that's not really just a lexical scope and not really just a subroutine scope it would be nice to give it a name and a definition somewhere rather than having to repeat the awkward scoping rules every time. Or maybe the issue is its not entirely obvious that eval STRING establishes a new lexical scope. I know I didn't realize it until recently. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 11:35:46PM +0200, Abigail wrote: On Tue, Jul 26, 2005 at 05:37:39PM +0100, Nicholas Clark wrote: So is wantarray's value is only specified within a subroutine or method which was called directly by other perl code true? No. $ perl -wle 'print eval wantarray' 1 $ No subroutine, no method. A quick look at the src shows that it scans back through the current context stack for an eval, sub or format. From this perspective, a require or do file is an eval. If it it fails to find one, it returns undef. It doesn't scan previous context stacks, so it wont backtrack through magic, tie, overload etc. -- The perl5 internals are a complete mess. It's like Jenga - to get the perl5 tower taller and do something new you select a block somewhere in the middle, with trepidation pull it out slowly, and then carefully balance it somewhere new, hoping the whole edifice won't collapse as a result. - Nicholas Clark, based on an original by Simon Cozens.
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 11:27:05PM +0100, Dave Mitchell wrote: A quick look at the src shows that it scans back through the current context stack for an eval, sub or format. From this perspective, a require or do file is an eval. If it it fails to find one, it returns undef. It doesn't scan previous context stacks, so it wont backtrack through magic, tie, overload etc. Oh. Interesting. I had a chat with Robin Houston (author of Want) about this. Robin says that Want can't scan back past a tie, because the information it would need is in a local variable in a C function. (He was telling me this. I think he told me which function, but it wasn't all sinking in, as things have been a bit http://www.flickr.com/photos/twoshortplanks/28698637/ recently *) Would the core not being able to scan back past tie/overloading/magic/etc be a bug that needs addressing? Nicholas Clark * to avoid confusion I should clarify that that photo was from the meeting on Monday. I was talking with Robin at the meeting on Thursday. ** to avoid distress I should clarify further that neither copenhagen.pm nor the state of the glass have anything to do with the aargh. Nor does any open source code. We know where the code in question lives, and its days are numbered. :-)
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 11:40:01PM +0100, Nicholas Clark wrote:
Would the core not being able to scan back past tie/overloading/magic/etc
be a bug that needs addressing?
I don't think so. Since the first thing that happens with tie, overload
etc is that it calls a sub, there will always be a sub context at the base
of the new context stack to be found. If it hasn't invoked a sub (eg
PERLSI_MAGIC), then it's hardly likely to be able to execute pp_wantarray.
Note that most context stack searching in Perl only searches the *current*
context stack, eg looking for labels with next or goto:
#!/usr/bin/perl
sub TIEARRAY { goto FOO }
my @a;
tie @a, 'main';
FOO:
$ perl587 /tmp/p
Can't find label FOO at /tmp/p line 3.
$
--
In my day, we used to edit the inodes by hand. With magnets.
