Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

wantarray documentation in 5.8.7

by polettix (Vicar)
on Jul 25, 2005 at 11:15 UTC ( #477759=perlquestion: print w/ replies, xml ) Need Help??
polettix has asked for the wisdom of the Perl Monks concerning the following question:

The latest documentation for wantarray show this addition with respect the previous version:
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.
dree and I were wondering about the exact meaning of top level of a file. I mean, if I use do on a file, I get a context for wantarray to work on even if it's at the top level of the file.

I initially thought that it had to be changed into something including scope, but after some chatterboxing with virtualsue and bart I realised that scope has nothing to do in this case. How should the sentence be rephreased in order to get it completely correct?

Update: I expanded with a couple examples in my answer to tlm in Re^2: wantarray documentation in 5.8.7.

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

Don't fool yourself.

Comment on wantarray documentation in 5.8.7
Re: wantarray documentation in 5.8.7
by tlm (Prior) on Jul 25, 2005 at 11:53 UTC

    ...if I use do on a file, I get a context for wantarray to work on even if it's at the top level of the file.

    I'm not sure what you mean by this, but here's an example in which wantarray doesn't seem to work at the top level:

    % perl -wle 'my @x = do { wantarray ? q(yes) : q(no) }; print $x[0]' no
    ...though the above was obtained with v. 5.8.4. But even if the output above had been "yes", it wouldn't have contradicted the docs. The docs are simply saying that the behavior is unspecified, i.e. don't write code that depends on this behavior because it is liable to be not portable or being broken by future releases of Perl. It seems very clear to me.

    the lowliest monk

      if I use do on a file, I get a context for wantarray to work on even if it's at the top level of the file.
      I'm not sure what you mean by this ...

      If you use the do operator to evaluate the contents of a file then code in that file gets the context of the do, so in those circumstances wantarray is meaningful to code at the top level of a file.

      ... but here's an example in which wantarray doesn't seem to work at the top level

      Well done. Now the actual purpose of this thread is to find a form of words that distinguishes these cases, so the docs can be patched to avoid the current inaccuracy which suggests that wantarray is never meaningful at the top level.

      Smylers

        Now the actual purpose of this thread is to find a form of words that distinguishes these cases, so the docs can be patched to avoid the current inaccuracy which suggests that wantarray is never meaningful at the top level.

        The docs say nothing of whether wantarray it is "meaningful" or not at the top level. All they say is that its behavior at the top level is officially unspecified. I.e. two different releases of Perl may exhibit different behaviors and both be within spec.

        the lowliest monk

        Now the actual purpose of this thread is to find a form of words that distinguishes these cases, so the docs can be patched to avoid the current inaccuracy which suggests that wantarray is never meaningful at the top level.

        I would guess, although I have not tested it, that the talk about the "top level" also applies to code entered via -e, even though that's not "a file."

        The distinction seems to be about the "main" source code, so I'd say: "wantarray()'s result is unspecified in the top level of a source file a program's main source code, in a BEGIN , CHECK , INIT or END block, or in a DESTROY method."

        Perhaps "main source code" isn't the right phrase, but it's closer to the point than "a source file."

      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!";
      When called directly, it yelds:
      wantarray undefined!
      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";
      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!
      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.
        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!"; };


        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");


        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";


        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').

        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.

        the lowliest monk

Re: wantarray documentation in 5.8.7
by Anonymous Monk on Jul 25, 2005 at 13:27 UTC
    What is meant is that wantarray is meaningless if there is no calling context. Which is the case in a BEGIN, CHECK, INIT or END block, a DESTROY method, and the "top level of a file" when you're executing that file. Obviously, it has not much to do with the physical location of the code in a file (although the "top level" is often located at the top).

    Of course, you could change it to "when there's no calling context", but then half a year down the road, someone will find that sentence confusing, and change to "top level of a file".

      Of course, you could change it to "when there's no calling context", but then half a year down the road, someone will find that sentence confusing, and change to "top level of a file".
      Which will make it confusing for others. A no-op seems wrong to me in this case; maybe the better thing is to make an effort to definitely clarify this matter.

      What we really lack here is maybe a formal definition of context, and in particular of when you have a context and when you don't have it. I know that perldata has an entire section about context, but the definition results quite foggy IMHO, and resorts to wantarray to disambiguate. The classic dog-biting-its-own-tail problem. Moreover, I'm not in the position to propose an alternative, and this is quite frustrating.

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

      Don't fool yourself.
        Moreover, I'm not in the position to propose an alternative, and this is quite frustrating.
        Anyone is in the position to propose any alternative. It's done by sending a message to p5p, stating your case. Attaching a patch to your case strengthens it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://477759]
Approved by Tanalis
Front-paged by jbrugger
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (7)
As of 2014-08-27 08:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (232 votes), past polls