scope of labels
Henry S. Thompson
works, it SHOULD work) that I can use loop control inside a
subroutine, e.g.
undef $resvar;
CASE: {
&testAndSet("p1",/p1/);
&testAndSet("p2",/p2/);
. . .
}
sub testAndSet {
local($val,$test) = @_;
if ($test) {
$resvar=$val;
last CASE
}
}
Sorry if this is a FAQ, but didn't find it in the version I snarfed . . .
ht
--
Henry Thompson, Human Communication Research Centre, University of Edinburgh
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 31 650-4440
Fax: (44) 31 650-4587 ARPA: h...@cogsci.ed.ac.uk JANET: h...@uk.ac.ed.cogsci
UUCP: ...!uunet!mcsun!uknet!cogsci!ht
Larry Wall
: Is it a bug (I'm getting away with murder) or a feature (it not only
: works, it SHOULD work) that I can use loop control inside a
: subroutine, e.g.
:
: undef $resvar;
: CASE: {
: &testAndSet("p1",/p1/);
: &testAndSet("p2",/p2/);
: . . .
: }
:
: sub testAndSet {
: local($val,$test) = @_;
: if ($test) {
: $resvar=$val;
: last CASE
: }
Like goto, it's one of those blessed but despised feature. In Perl 5
it warns you about it if you use -w, but it will do it. You can even
get away with it inside eval or s///e.
I believe in giving you enough rope to hang your problem.
I thought about making return behave similarly inside an eval (that is,
returning from the nearest dynamically enclosing subroutine), but I
decided instead that most people would expect a return in an eval
to return from the eval. On top of which, there was no comparable
way to short-circuit an eval, so return now just terminates the nearest
enclosing eval or subroutine.
By the way, just as a style note, I'd put a semicolon on the end of
"last CASE" even though it's not necessary. (Though I can see an
argument for always omitting the semicolon in the specific case of
"last" and "next". That way if anyone does add a line after them, they
blow up at compile time. (Well, *probably* blow up...))
My usual practice (when I'm not striving for backward compatibility) is
to omit the semicolon only on single-line blocks. For instance, I
wouldn't bat an eye if you wrote:
if ($test) { $resvar = $val; last CASE }
My argument for that is that the final bracket would have to be moved
down to the next line anyway if you added another statement, so you'd
be likely to notice the missing semicolon. On a multiline block it's
just too easy to add another statement and not see what isn't there.
Larry
Tom Christiansen
:Is it a bug (I'm getting away with murder) or a feature (it not only
:works, it SHOULD work) that I can use loop control inside a
:subroutine, e.g.
LABELs are dynamically scoped. That means that if you next/last/redo
some label not in your lexical scope, you're relying upon calling
order, on who called you. That's kinda scary. I've only used it from
within a carefully controlled interrupt routine. I don't think it's
documented, but I'd be surprised if it went away. Larry, what's
this do on Perl5?
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
It's there as a sop to former Ada programmers. :-)
--Larry Wall regarding 10_000_000 in <11...@jpl-devvax.JPL.NASA.GOV>
Larry Wall
: From the keyboard of h...@cogsci.ed.ac.uk (Henry S. Thompson):
: :Is it a bug (I'm getting away with murder) or a feature (it not only
: :works, it SHOULD work) that I can use loop control inside a
: :subroutine, e.g.
:
: LABELs are dynamically scoped. That means that if you next/last/redo
: some label not in your lexical scope, you're relying upon calling
: order, on who called you. That's kinda scary. I've only used it from
: within a carefully controlled interrupt routine. I don't think it's
: documented, but I'd be surprised if it went away. Larry, what's
: this do on Perl5?
As I mentioned elsewhere, it works, with potential warnings.
What's really whacked out is that goto behaves similarly. It unwinds
contexts one by one until it finds a context containing the specified
label. Enough rope...
Larry
Erik Johansen (Systemprogrammer)
I hope that the unwinding stops and returns a warning if it exits
an eval context, so there is no way to exit an eval.
Is this correct ?
Erik Johansen / Institute for Computer Science / Danish Technical University
e...@id.dth.dk
--
Erik Johansen / Institute for Computer Science / Danish Technical University
e...@id.dth.dk
Larry Wall
: lw...@netlabs.com (Larry Wall) writes:
:
: >In article <1993Feb25....@news.eng.convex.com> tch...@convex.COM (Tom Christiansen) writes:
: >: From the keyboard of h...@cogsci.ed.ac.uk (Henry S. Thompson):
: >: :Is it a bug (I'm getting away with murder) or a feature (it not only
: >: :works, it SHOULD work) that I can use loop control inside a
: >: :subroutine, e.g.
: >:
: >: LABELs are dynamically scoped. That means that if you next/last/redo
: >: some label not in your lexical scope, you're relying upon calling
: >: order, on who called you. That's kinda scary. I've only used it from
: >: within a carefully controlled interrupt routine. I don't think it's
: >: documented, but I'd be surprised if it went away. Larry, what's
: >: this do on Perl5?
:
: >As I mentioned elsewhere, it works, with potential warnings.
:
: >What's really whacked out is that goto behaves similarly. It unwinds
: >contexts one by one until it finds a context containing the specified
: >label. Enough rope...
:
: I hope that the unwinding stops and returns a warning if it exits
: an eval context, so there is no way to exit an eval.
:
: Is this correct ?
Why should Perl enforce such a fascist restriction? By definition, if
you're using goto, you're trying to do something gonzo. Or are you
thinking of goto as some kind of fatal error that eval should trap? :-)
Mind you, I never use goto myself. It's just that the philosophical
roots of Perl come from the Unix notion of freedom of expression. I
believe in well-thought-out rules, but I don't much believe in
arbitrary restrictions. True discipline comes from inside, not from
outside. From Grace, not from Law. Where social rules and social
conventions become equally restrictive, all artists are criminals.
Sorry, you pushed one of my hotter hot buttons.
If you want to see some interesting arbitrary restrictions, go read the
Rexx book. Like, a conditional expression MUST return 0 or 1. Hex and
binary strings can have embedded whitespace, but ONLY in certain
locations. It's an error to use something as a number that doesn't
look ENTIRELY like a number. And, of course, there's no GOTO...
Certainly, I've put some restrictions into Perl, but they tend to be
of a more basic sort. You can't have a subroutine with multiple
entry points. You can't write a dangling "then" statement. You can't
use a variable for a label. These are meaningful restrictions that
tend to increase the functionality or efficiency of other parts of
the language. However, I am never happier than when someone tries
something in Perl that they don't expect to work, and it does anyway.
Larry
Christopher Davis
LW> However, I am never happier than when someone tries something in Perl
LW> that they don't expect to work, and it does anyway.
Like s/foo/bar/ee? That one was *amazing*.
--
* Christopher Davis * <c...@eff.org> * <c...@kei.com> * [CKD1] * MIME * RIPEM *
226 Transfer complete. 17512509 bytes received in 5.2e+02 seconds (33 Kbytes/s)
Marc Horowitz
As the tired person who didn't quite realize what he was doing at the
time, I have to concur :-)
Marc
Timothy A McDaniel
Wall) writes:
>However, I am never happier than when someone tries
>something in Perl that they don't expect to work, and it does anyway.
Larry, what happens when they try something *you* didn't expect to work,
and it works anyway? Its working may have been a quirk of the code, and
it may have odd and suboptimal semantics, but now someone depends on it.
When you release a new version, either
- you break someone's working code
or
- you have to maintain this quirk, which may be truly odd
I'm thinking of an early IBM computer (701?), which had some
unimplemented opcodes. Some users tried them, and found they did
something odd but useful. They used them to bum cycles out of the code.
When IBM released the upward-compatable version (1401?), they had to
support some of these opcodes with their warts.
Has this happened yet?
--
Tim McDaniel, Convex Computer Corporation, Richardson, TX
mcda...@convex.com, mcda...@cyberspace.org, mcda...@adi.com
Christopher Davis
TAM> == Timothy A McDaniel <mcda...@convex.com>
LW> However, I am never happier than when someone tries something in Perl
LW> that they don't expect to work, and it does anyway.
TAM> Larry, what happens when they try something *you* didn't expect to work,
TAM> and it works anyway?
[...]
TAM> Has this happened yet?
Larry, unlike IBM (example deleted), appreciates the value of serendipity.
This is exactly what I was referring to in the case of s/foo/bar/ee; it was
discovered by accident, the discoverer asked about it here, Larry replied
"Um, no, I didn't know that worked either, but it looks useful enough to
keep."
(It does a double-eval after the substitution; among its other uses was the
famous "Old MacDonald" JAPH, which is still my favorite...)
Larry Wall
: In article <1993Feb28.0...@netlabs.com> lw...@netlabs.com (Larry
: Wall) writes:
: >However, I am never happier than when someone tries
: >something in Perl that they don't expect to work, and it does anyway.
:
: Larry, what happens when they try something *you* didn't expect to work,
: and it works anyway? Its working may have been a quirk of the code, and
: it may have odd and suboptimal semantics, but now someone depends on it.
: When you release a new version, either
: - you break someone's working code
: or
: - you have to maintain this quirk, which may be truly odd
Fortunately, the first person to discover such a quirk generally posts
it to this newsgroup immediately so that I can pass judgement. On the
one hand, in the case of s///ee, I blessed it. (In Perl 5, I had to
put in explicit code to support it, but I didn't mind.)
On the other hand, I don't hesitate to break undocumented misfeatures.
Anyone who depends on undocumented behavior is just asking for a life
of misery, in my arrogant opinion.
On the gripping hand, I should point out that the situation doesn't arise
very often in well-coded interpreters. :-)
: I'm thinking of an early IBM computer (701?), which had some
: unimplemented opcodes. Some users tried them, and found they did
: something odd but useful. They used them to bum cycles out of the code.
: When IBM released the upward-compatable version (1401?), they had to
: support some of these opcodes with their warts.
Fortunately, it's easier to keep an old interpreter around than an
old computer.
Larry
Steven Grady
> Like goto, it's one of those blessed but despised feature. In Perl 5
> it warns you about it if you use -w, but it will do it. You can even
> get away with it inside eval or s///e.
Hmmph. I'm offended. You can indeed do a goto from an evaluated
regexp, but you can't goto a label which appears inside a regexp.
I.e., the following doesn't do anything ... interesting:
#!/usr/gnu/bin/perl
$foo = 'hello';
print "foo #0: $foo\n";
$foo =~ s/l/foo:'x'/e;
print "foo #1: $foo\n";
goto foo;
I'm sure what exactly it should do, but currently it just complains that
it can't find any label "foo".. I'm sure one could do something truly
unintelligible^H^H^H^H^H^H^H^H^H^H^H^H^H^Huseful with this functionality..
--
Steven
gr...@lotus.com
"Good morning, Lance...How goes it?"
"I think I'm operating at about 50 percent today, Lars... due
to the amount of sleep I got."
"Half your usual amount?"
"Twice my usual amount... I usually operate at 25 percent."
Larry Wall
: In article <1993Feb25.1...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
: > Like goto, it's one of those blessed but despised feature. In Perl 5
: > it warns you about it if you use -w, but it will do it. You can even
: > get away with it inside eval or s///e.
:
: Hmmph. I'm offended. You can indeed do a goto from an evaluated
: regexp, but you can't goto a label which appears inside a regexp.
: I.e., the following doesn't do anything ... interesting:
:
: #!/usr/gnu/bin/perl
: $foo = 'hello';
: print "foo #0: $foo\n";
: $foo =~ s/l/foo:'x'/e;
: print "foo #1: $foo\n";
: goto foo;
:
: I'm sure what exactly it should do, but currently it just complains that
: it can't find any label "foo".. I'm sure one could do something truly
: unintelligible^H^H^H^H^H^H^H^H^H^H^H^H^H^Huseful with this functionality..
Doing a goto into an eval would be a neat trick... :-)
The essential limitation of goto in Perl 5 is that you can't go into
anything that requires initialization. Unfortunately, substitutions,
evals, and subroutines all require initialization, as do SOME loops.
You can get away with
goto label;
while ($whatever) {
...
label:
...
}
but not with
goto label;
foreach (split(' ', $whatever)) {
...
label:
...
}
Mind you, even that first method comes highly unrecommended.
Larry
John Macdonald
|returning from the nearest dynamically enclosing subroutine), but I
|decided instead that most people would expect a return in an eval
|to return from the eval. On top of which, there was no comparable
|way to short-circuit an eval, so return now just terminates the nearest
|enclosing eval or subroutine.
Hmm, will this apply to "do <file>" and require as well? I find myself
wishing that the debugger "r" command could be used to skip out of these
and back to the invoking routine. (I know, I can use "c <location>" to
get the same effect, but it is kind of neat to just single-step along,
see where you got, and then "r" whenever you get into an area that does
not need tracing... Actually, I wouldn't mind if the "n" command would
treat do, require, and eval as if they were function calls and skip
them.)
Larry Wall
: In article <1993Feb25.1...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
: |
: |I thought about making return behave similarly inside an eval (that is,
: |returning from the nearest dynamically enclosing subroutine), but I
: |decided instead that most people would expect a return in an eval
: |to return from the eval. On top of which, there was no comparable
: |way to short-circuit an eval, so return now just terminates the nearest
: |enclosing eval or subroutine.
:
: Hmm, will this apply to "do <file>" and require as well?
Yes, since those are basically eval with some extra frills.
: I find myself
: wishing that the debugger "r" command could be used to skip out of these
: and back to the invoking routine. (I know, I can use "c <location>" to
: get the same effect, but it is kind of neat to just single-step along,
: see where you got, and then "r" whenever you get into an area that does
: not need tracing... Actually, I wouldn't mind if the "n" command would
: treat do, require, and eval as if they were function calls and skip
: them.)
Good idea. I haven't worked up the debugger for Perl 5 yet, so I'll
try to keep that in mind when I do.
Larry