in reply to Re^6: 'return:' instead of 'return'
in thread 'return:' instead of 'return'
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.
|
|---|