in reply to Re^4: 'return:' instead of 'return'
in thread 'return:' instead of 'return'

But what does 'return' evaluate to?
When in doubt, don't consult Perlmonks. Read the documentation. Not only do you get your answer faster, it isn't buried between posts that don't answer your questions. It also doesn't require other people to read the documentation for you.
$ perldoc -f return return EXPR return Returns from a subroutine, "eval", or "do FILE" with th +e value given in EXPR. Evaluation of EXPR may be in list, scal +ar, or void context, depending on how the return value will be + used, and the context may vary from one execution to the next + (see "wantarray"). If no EXPR is given, returns an empty li +st in list context, the undefined value in scalar context, an +d (of course) nothing at all in a void context. (Note that in the absence of an explicit "return", a subroutine, eval, or do FILE will automatically return +the value of the last expression evaluated.)

Replies are listed 'Best First'.
Re^6: 'return:' instead of 'return'
by Boldra (Curate) on Jun 12, 2009 at 12:21 UTC
    This still doesn't explain what 'return 3' evaluates to, just what it returns. I'm very sorry if you feel reading my posts was a waste of your time, JavaFan, I don't feel that reading yours was a waste of my time, so I thank you for your patience.


    - Boldra

      In a coroutine/continuationless language, return never evaluates to a value. It only transfers control to the caller one level up the call stack. You can see this for Perl by looking at the following code:

      Q:\>perl -wle "my $foo; sub f { $foo = return 'bar' }; f(); print $foo +" Use of uninitialized value in print at -e line 1. Q:\>perl -wle "my $foo='x'; sub f { $foo = return 'bar' }; f(); print +$foo" x

      In neither case, $foo was changed, because return does not have a "expression value" in Perl.

      If Perl was a language that had real continuations (Coro left aside), you could invent in that alternate universe a value to be returned from return 'bar', which would modify the flow of control:

      sub f { my $position_of_caller = return 3; # f() will be '3', eventually my $alternative = return 5; # f() will be '5', eventually print "Now we return a value:"; $alternative->(); # return 5 to caller # will we get here? Possibly, through the "yield" call. CONTINUATION: print "We are continuing here?"; }; f(); yield; # transfers control to the label CONTINUATION

      Coro has something like this, and having different strains of execution throughout your program allows you for example to have something like threads except without the locking problems. You won't get true parallelism through it, and playing with bare continuations can bet quite complex soon.

      An interesting question is for example what would/should happen if you call f() twice without an intervening yield; statement.

      The problem here Boldra is that you have been given the correct answer multiple times, and you are not accepting it. Let me restate it for you (and I intend this respectfully):

      The label is created. The last value is returned in your example.

      You followed with examples that do not reflect your problem and continued to resist the answer. Next time, give an example that is the problem. That way no one will feel as if their time was wasted.

      Lastly, sometimes I feel as if folks hope their problem will result in a mystery or bug. This one is user error; please accept it.
      This still doesn't explain what 'return 3' evaluates to, just what it returns.
      It seems you think there's a difference between 'evaluating to', and 'returning'. Could you explain what you think the difference is, and could you give an example of a statement that, according to you, evaluates to something, but returns something else?