The end of dynamic scope

T

Todd

The dynamic scope is a slightly different defined compared with the
lexical scope when considier only the end boundary of the scope. Let
check the codes below:

#! /bin/perl -l

my $a1 = "old value";
if (my $a1 = "new value") {};
print "case `my' after <if block>: $a1";

our $a2 = "old value";
if (our $a2 = "new value") {};
print "case `our' after <if block>: $a2";

local $a3 = "old value";
if (local $a3 = "new value") {};
print "case `local' after <if block>: $a3";

local our $a4 = "old value";
if (local our $a4 = "new value") {};
print "case `local our' after <if block>: $a4";

__END__

case `my' after <if block>: old value
case `our' after <if block>: new value
case `local' after <if block>: new value
case `local our' after <if block>: new value

So here only the `my' variable decarlared in the condition expr of
<if block> totally disapeared after the if block.

May some one here give any hints on this?

Best regards,
Todd
 
T

Todd

The `our' case can't be ignored since it's acutally a global
variable.

But the 'local' case make things a little wondering, I ofen used
product level codes like

unless ($line =~ /...(\d+).../) {
ErrorLogging "something wrong from input";
return undef;
}
my $number = $1;
... # continue processing here

The point here is $1 is a local variable, according to the BOOK, the
scope is ended after the if-block, but obviously, the locally binded
$1's value is still there even after the if-block.

This is where my question comes from.

Thanks,
Todd
 
X

xhoster

Todd said:
The dynamic scope is a slightly different defined compared with the
lexical scope when considier only the end boundary of the scope. Let
check the codes below:

#! /bin/perl -l

my $a1 = "old value";
if (my $a1 = "new value") {};
print "case `my' after <if block>: $a1";

our $a2 = "old value";
if (our $a2 = "new value") {};
print "case `our' after <if block>: $a2";

Re-"our"ing a variable should be a no-op, shouldn't it?
local $a3 = "old value";
if (local $a3 = "new value") {};
print "case `local' after <if block>: $a3";

local our $a4 = "old value";
if (local our $a4 = "new value") {};
print "case `local our' after <if block>: $a4";

__END__

case `my' after <if block>: old value
case `our' after <if block>: new value
case `local' after <if block>: new value
case `local our' after <if block>: new value

So here only the `my' variable decarlared in the condition expr of
<if block> totally disapeared after the if block.

May some one here give any hints on this?

What kind of hint are you looking for? Yes, lexical variables have
somewhat weird scoping rules when declared in conditionals. But you seem
to have a good handle on what those are.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
 
T

Todd

What kind of hint are you looking for?  Yes, lexical variables have
somewhat weird scoping rules when declared in conditionals.  But you seem
to have a good handle on what those are.

My question is why the local binded value is still there even after
the block is ended. As you see, in the case of my variable, the scope
is ended.

So if you can answer the question, please go ahead.

-Todd
 
X

xhoster

Todd said:
My question is why the local binded value is still there even after
the block is ended. As you see, in the case of my variable, the scope
is ended.

From "local"s perspective, the conditional is not part of that block. And
purely lexically, it is not part of that block--the conditional is located
before the opening "{", not between the "{" and "}".

In an attempt to DWIM, "lexical" variables are effectively pushed down to
the block scope (or the scope is pulled up to meet them). I vaguely recall
something from the guts that there is some kind of pseudo-scope which
encompasses both the conditional and the block for those constructs which
have both, and that the pseudo-scope applies only lexically not
dynamically.

The basic answer to "why is it that way?" is "That is the way the
implementors implemented it." And thinking about the implications of the
alternatives, it seems to me like the only reasonable way to do it.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
 
T

Todd

the block scope (or the scope is pulled up to meet them). I vaguely recall
something from the guts that there is some kind of pseudo-scope which
encompasses both the conditional and the block for those constructs which
have both, and that the pseudo-scope applies only lexically not
dynamically.

Let's check more cases:

#! /bin/perl

$a = 1;
for (;local $a=3;) { last; }
print $a;

__END__
1

#! /bin/perl

$a = 1;
for (local $a=3;;) { last; }
print $a;

__END__
3

#! /bin/perl

$a = 1;
while (local $a=3) { last; }
print $a;

__END__
1

So it's a total mess to explain it decently, isn't it? :)

-Todd
 
T

Todd

Finally, i got the answer using -MTerse to check the op tree and the
PP codes.

1. IF case
`if (A) { B }' is equal as:
A and B
so here there is no new scope generated.

2. WHILE case
But for `while (local $a) { B}' it's parsed as:
it's enclosed in enterloop .. leaveloop, a real dynamic save stack
exists.

For my variable, it's compile time bounded based on lexical '{' '}'
text only, no dynamic scope create needed, so it's compile time only
scope.

Feel good to get rid of this frustration. :)

-Todd
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top