Double feature: the next statement
Alain Brossard
This "double feature" is present in Perl 4.019 on a Sun4 running
sunos 4.1.1.
When doing a next within a subroutine which is
called within a loop and the next itself is NOT within a loop, the next
is NOT flagged as an error but gives back the control outside the
subroutine. This first feature is NOT documented in the perl book and
I feel that it is a bug since the fact whether the statement is
syntacticaly valid depends on the USAGE of the subroutine rather than
its definition! Without the outside loop, I get an error message:
Bad label: <null> at - line 4.
The double part of this feature is that the subroutine can AFFECT
where the next statement returns OUTSIDE of it!! In the example below,
the PRESENCE of the NEVER executed return statement, affects whether
the statement "next" will give back control just after the call of
the subroutine or outside the loop which called the subroutine!
$once = 1;
while( $once ){
$once = 0;
&call_it( 'nothing' );
print STDERR "Comes back IN the loop\n";
}
print STDERR "Out of the loop\n";
sub call_it {
if( 0 ) { return 0 ; } # Pure MAGIC
print STDERR "Just before the next (proves return doesn't get done)\n";
next;
print STDERR "Never here, no error messages\n";
}
And the results are:
with the if/return statement:
Just before the next (proves return doesn't get done)
Comes back IN the loop
Out of the loop
without the if/return statement:
Just before the next (proves return doesn't get done)
Out of the loop
Alain
--
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
bros...@sic.epfl.ch
Larry Wall
:
: This "double feature" is present in Perl 4.019 on a Sun4 running
: sunos 4.1.1.
: When doing a next within a subroutine which is
: called within a loop and the next itself is NOT within a loop, the next
: is NOT flagged as an error but gives back the control outside the
: subroutine. This first feature is NOT documented in the perl book and
: I feel that it is a bug since the fact whether the statement is
: syntacticaly valid depends on the USAGE of the subroutine rather than
: its definition! Without the outside loop, I get an error message:
: Bad label: <null> at - line 4.
:
: The double part of this feature is that the subroutine can AFFECT
: where the next statement returns OUTSIDE of it!! In the example below,
: the PRESENCE of the NEVER executed return statement, affects whether
: the statement "next" will give back control just after the call of
: the subroutine or outside the loop which called the subroutine!
Okay, I'll give you a third feature that goes with the other two. In a
subroutine containing a return, you can say "redo _SUB_" and it will start
the subroutine over.
Here's a fourth. You can exit an eval by saying "last _EVAL_".
How 'bout this:
FOO: {
eval ' print "Ever\n"; eval "redo FOO"; print "Never\n"; ';
}
These are all accidents of an implementation using longjmp() and a
dynamic label stack, and the wise programmer will not make use of
them. If you want me to be totally strict about such things, then
don't complain if Perl becomes twice as big, twice as slow, and has to
be rewritten in C++. I'm sure the Book could have been made twice
as big too.
If I don't document something, it's usually either for a good reason,
or a bad reason. In this case it's a good reason. :-)
Larry
Root Boy Jim
>In <23...@sicsun.epfl.ch> bros...@sicsun.epfl.ch (Alain Brossard) writes:
>:
>: This first feature is NOT documented in the perl book and...
...should be. Those familiar with LISP `catch' and `throw' will
have no problem. This is a useful thing. Unfortunately, you don't
get to throw a value.
>Okay, I'll give you a third feature that goes with the other two. In a
>subroutine containing a return, you can say "redo _SUB_" and it will start
>the subroutine over.
>
>Here's a fourth. You can exit an eval by saying "last _EVAL_".
>These are all accidents of an implementation using longjmp() and a
>dynamic label stack, and the wise programmer will not make use of them.
Unfortunately, longjmp contains a system call.
>If you want me to be totally strict about such things, then
>don't complain if Perl becomes twice as big, twice as slow, and has to
>be rewritten in C++. I'm sure the Book could have been made twice
>as big too.
Or it could have been made twice as small.
Rewriting in C++ might be A Good Thing.
>If I don't document something, it's usually either for a good reason,
>or a bad reason. In this case it's a good reason. :-)
Please document these things or forbid them. It should be easy enuf
to set a special bit in your symbol table.
>Larry
--
Desolation Row Jimmy <r...@uunet.uu.net>
Drawing Crazy Patterns on Your Screen