Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.lang.perl
Subject: Re: Weird response of "next" inside sub?
Message-ID: <125276@uunet.UU.NET>
Date: 11 Mar 91 19:09:24 GMT
References: <1991Mar6.172554.14299@iwarp.intel.com> <124820@uunet.UU.NET> <11706@jpl-devvax.JPL.NASA.GOV>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 57

In article <11706@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>In article <124820@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
>: In article <1991Mar6.172554.14299@iwarp.intel.com> merlyn@iwarp.intel.com (Randal L. Schwartz) writes:
>: >Watch this:
>: >
>: >Yow!  The next exits the sub and cycles the outer "for" loop!  (This
>: >bit me in a program today.)
>: 
>: I say leave it in. This is like catch/throw or setjmp/longjmp.
>: As long as the subroutines are cleaned up ok, I'm all for it.
>
>I think the subroutine is cleaned up okay, but it's still rather presumptous
>of the subroutine to decide it was called from within a loop. And note that
>"next" is more or less equivalent to a return if there is a return statement
>in the subroutine, since return is implemented internally using a BLOCK.

This is bad, because there no way to know this unless you
hack on perl's innards.

>You'd still be able to say "next FILE", or whatever.

This is almost equivalent to a catch/throw pair!

>Guess what this does:
>
	sub foo {
	    return unless @_;
	    print "I say, ";
	    while ($_ = shift) {
		redo _SUB_ if /^;$/;
		print $_," ";
	    }
	}
	&foo(now,is,';',the,time);

It doesn't print: "I say, now is I say, the time" :-)

What are the rules for naming these blocks. Are they all called _SUB_?
Why not call them _FOO_, _BAR_, etc?

>Larry

Tom Christiansen sez:
>
>Boo.  Hiss.  This is too easy to screw up, and not flexible
>enough for exception handling.  That's what eval/die give you.

As mentioned above, tis more or less catch/throw. And I'm
reluctant to use eval/die for this. Actually, eval/die is less
powerful than catch/throw or setjmp/longjmp, as there is only one
possible return point with the eval/die. Also, I am reluctant to
use eval often, even in LISP. I find the scoping slightly more
difficult to figure out.

-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane