Sorry, forgot to hit reply-all.
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Date: Mon, 28 Oct 2002 12:58:16 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
> Subject: Re: labeled if blocks
> To: Larry Wall <[EMAIL PROTECTED]>
>
>
> --- Larry Wall <[EMAIL PROTECTED]> wrote:
> > On Mon, 28 Oct 2002, Austin Hastings wrote:
> > : How about "leave"?
> >
> > Right, that brings back some memories.
> >
> > : leave
> > : <SURROUNDING> | [<SURROUNDING>]<IDENTIFIER>
> > : [ [result] <VALUE-SPEC> ];
> > :
> > : Aliases:
> > : =========
> > : return -> "leave sub"
> >
> > Right.
> >
> > : exit -> "leave program" (or is it "thread"?)
> >
> > Hmm. Dunno. I'll assume thread for now. At least under some
> > thread models, it's the main thread's exit that counts for the
> > program exit. But I'm not a threading expert (yet).
>
> I've always hated that paradigm. But you're right. Threads need exit
> codes, too.
>
> leave thread result (0 but true);
>
> > : break -> "leave loop" (this is shaky: does it deserve to be
> here?)
> >
> > That's "leave switch", or "leave topic", or some such, I'd think.
>
> How do you leave a topic without also leaving the block wrapping it?
> Will there be a resume topic?
>
> with $x -> {
> ...
>
> leave topic;
> print $_;
> resume topic $x;
> ...
> }
>
> Can the perl-poets count on "off" as a synonym for "leave"?
>
> ...
> $luser.sendmail($flame) if off topic; # :-p
> ...
>
> > : last -> "leave block"
> >
> > That's "leave loop", I expect.
>
> How to differentiate? As far as I can tell, the only value in
> discriminating among "leave topic", "leave block", and "leave loop"
> is
> to save putting a label on the containing curly.
>
> This may be value enough.
>
> How likely is this to be useful in an "anoynmous programming"
> context,
> such as a filter, where the containing structures are not known to
> the
> code author? (IOW: If I want to write a "break_loop" verb, being able
> to say "leave loop" is really valuable.)
>
> >
> > What I'm thinking of as "ret" is:
> >
> > ret leave block
> > ret $x leave block, $x
>
> I like the comma, if "result" is a synonym for whitespace:
>
> leave block, result $x;
>
> Which extends to longjmp:
>
> leave $jb, result $x; # AKA leave $jb, $x;
>
> > One could argue that leaving the innermost block should be the
> > default, but that doesn't quite make "leave" a synonym for "ret".
> > It's one of those situations where you want to have two different
> > defaults in different situations. Hmm. Suppose instead of
> > a function, we have a method, and scope matching happens via
> > class just as with exceptions:
> >
> > return -> Sub.leave
> > return $x -> Sub.leave($x)
> > exit -> Thread.leave
> > exit $x -> Thread.leave($x)
> > break -> Topic.leave
> > last -> Loop.leave
> > last LABEL -> Loop.leave(label => "LABEL")
> > ret -> Block.leave
> > ret $x -> Block.leave($x)
> >
> > Then you could also have a global sub *leave that defaults to
> Block.
> > Then "ret" is officially unnecessary, since you could say
> >
> > leave($x)
> >
> > Except that "leave" doesn't read right for that--sounds like you're
> > wanting to "leave $x". Maybe it's
> >
> > leave(value => $x)
>
> leave result $x; # Scans okay.
>
> >
> > but that's not very concise. Perhaps it doesn't matter, since
> > the usual way to return a value from a block looks like this:
> >
> > {
> > ...
> > $x;
> > }
> >
> > But if you're gonna define a global sub anyway to default the
> > invocant,
> > maybe *ret will be more meaningful to people than *leave.
>
> Not me. leave changes stack frame, ret pops. Plus, ret doesn't scan
> for
> loop control and stuff.
>
> > Or maybe it should be *val.
> > Except that val($x) could be misread as setting the
> > value without returning...
>
> I agree with the exception. "val" sounds like a prelude to "0 but
> true"
> from a distance. (Kind of like Pascal's automatic creation of a
> variable with the same name as all functions:
>
> fibonacci := 1; # val(1);
>
>
> > : Extensions (these are WAY! optional):
> > : ==========================
> > : enter $jb BLOCK;
> > : leave $jb [result $val];
> >
> > I'd say those would map to
> >
> > $jb.enter {...}
> > $jb.leave(value => $val);
> >
> > presuming we wanted to get that fancy, which most of us won't.
>
> Just you wait. EmbeddedPerl is coming. :-O
>
> > An exception handler is just a closure property.
> > Anything like an exception handler is also just a closure
> > property.
> > Control flow is just a kind of exception.
>
> Hmm. So perhaps "leaving" is a superoperation of "throwing". That is
> to
> say, "throw" takes a value and carries it upstack until a
> smartmatching
> "catch" block is found, evaluating finally clauses all the while.
>
> And "leave" takes a value and a "frametype" and carries it upstack
> until a matching "frametype" is found.
>
> So a throw is just a leave with a "frametype" of a sub that looks at
> the stack/block/topic frame and tries to smartmatch catch-blocks?
>
> Yikes!
>
>
>
> > I do realize that every time we say "an A is just a B", it's really
> a
> > kind of fib, because they're all oversimplifications, particularly
> > when
> > the concept B is more complicated than the concept A. A closure is
> > arguably harder to understand than a block, after all. But this is
> > how
> > I think, and Perl 6 is going to be full of it, one way or another.
>
> You said it first. ;-) ;-) ;-)
>
> As long as the "an A is just a B" statements all have the A's and B's
> in the right order. I'm reminded of textbooks that say "A for loop is
> like a while loop written this way ... <horrible construct> ...
> except
> that the increment step is always executed and ... <blather>"
>
> It's a lot easier to say "a while loop is a for loop with the
> initialization and increment blocks kept empty."
>
> Get the A's and B's on the correct sides, and things fall into place.
>
> =Austin
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
