Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Can't localize lexical variable $var at...

by Courage (Parson)
on Jun 09, 2002 at 17:55 UTC ( #172935=perlquestion: print w/replies, xml ) Need Help??
Courage has asked for the wisdom of the Perl Monks concerning the following question:

"perldoc perlguts" command reads:
Perl has a very handy construction { local $var = 2; ... } This construction is *approximately* equivalent to { my $oldvar = $var; $var = 2; ... $var = $oldvar; }
... and this works as expected:
D:\>perl -lwe "$var='qq';{local $var=2;print $var;}print $var" 2 qq
However this does not work:
D:\>perl -lwe "my $var='qq';{local $var=2;print $var;}print $var" Can't localize lexical variable $var at -e line 1.
Does anyone knows about a reason (I beleive there should be)why perl refuses to localize variables declared via my?
This seemed to be quite useful feature if it could, whereas current limitation looks not very perlish.

Courage, the Cowardly Dog.

Replies are listed 'Best First'.
Re: Can't localize lexical variable $var at...
by Elian (Parson) on Jun 09, 2002 at 18:02 UTC
    The docs are pretty clear on this--you can only localize global variables.

    This is partially for hysterical raisins, as global variables and local predated lexicals by quite a bit in perl's history. Local is a hackish way to implement lexical scope without lexical variables.

    There's also little reason to use local with a lexical--since local overrides a variable until the end of the scope, you might as well either overwrite the lexical (if it's in the scope the lexical was declared) or my a new version of the lexical (if it's in an inner scope from the declaration).

      Just for completeness, you can localize an element of a lexical hash or array. How useful this is, I don't know.
      #!/usr/bin/perl use warnings; my %hash = (a=>1, b=>2); { local $hash{'a'} = 999; print map {"$_ = $hash{$_}, "} sort keys %hash; print "\n"; } print map {"$_ = $hash{$_}, "} sort keys %hash; print "\n";
      I've always been a little confused as to why this was implemented for elements of a lexical hash or array but not scalar


      "To be civilized is to deny one's nature."
        That's one of the things that slipped in under the radar. There's no real difference between elements of a lexical and global array or hash, so you can localize either with no penalty. It's a quirk of the implementation--whether it's a bug or not is arguable. (local's already got a number of problems, mainly when localizing anything with magic)
Re: Can't localize lexical variable $var at...
by Kanji (Parson) on Jun 09, 2002 at 18:07 UTC

    You can find some additional enlightenment in Dominus' Coping with Scoping, but to get the same effect with a my-declared variable, you can just redeclare it in a different scope (ie, inside a { ... }).

    perl -lwe "my $var='qq';{my $var=2;print $var;}print $var"


Re: Can't localize lexical variable $var at...
by ariels (Curate) on Jun 09, 2002 at 19:05 UTC
    That's because... can't localize a lexical variable. It doesn't make any sense.

    A lexical variable has visibility limited by space: it is visible precisely within its scope, from the point of definition to the end of that block. It is known (except if shadowed) by its name throughout the scope, and it does not exist anywhere outside its scope. In particular, a sub outside the scope cannot see that variable.

    Compare with a localized instance of a global variable. This has its visibility limited by time: it starts having its new value when local is executed, and continues with that value until execution of that block finishes. As such, to know its value you have to know about the particular execution path in effect. At different times, the same reference to a global variable may refer to totally different instances of it; a reference to a lexical variable always refers to the the same variable.

    Consider a function (external to the scope) which uses a lexical <samp>$x</samp>. It always refers to the same <samp>$x</samp>, and calling code cannot change that. A function which uses a global <samp>$x</samp>, by contrast, refers to the current instance of <samp>$x</samp>; calling functions can change which instance that is.

    Generally, global variables are useful for options. For instance, if your functions refer to a global variable $debug, you can turn on debugging for the entire program by saying "$debug=1" at the top. But you can also turn on debugging just for a small portion of the run by saying

    { local $debug = 1; # Code here prints debugging messages # ... } # Code here reverts to the old status
    You can't do that (conveniently) with lexicals.

    Mixing the 2 is (to mix a metaphor; sorry) mixing time and space; it just doesn't work.

      Mixing the 2 is (to mix a metaphor; sorry) mixing time and space; it just doesn't work.
      Ah, if things were only that simple. I can make a lexical hash. The scope of its elements is limited by space. Yet I can localize such elements.

      Note that perl-5.000 to perl-5.000o do allow you localize a lexical variable. perl-5.001 no longer allows that. The Changes file on 5.001 says:

      NETaa13502: now complains if you use local on a lexical variable
      From: Larry Wall
      Files patched: op.c
       Now says something like
           Can't localize lexical variable $var at ./try line 6.

      I cannot find a rationale though - perhaps the p5p archives have such a rationale, if they go back that far.


      you wrote:
      In particular, a sub outside the scope cannot see that variable.

      But subs inside that scope are able to see that! And I cleanly see a way how that lexically scoped variable could be stacked, just like global variable!

      But yes, I'll better just use lexical variables and implement stacking if I really need.

      Best wishes,
      Courage, the Cowardly Dog

        No, it cannot. If you { my $var; some_sub(); }, then some_sub() cannot see $var. On the other hand, if you { local $var; some_sub(); }, then some_sub() can. (And that's why you shouldn't local unless you have a clear reason for it and not before you have signed a contract that you clearly understand that perl is not liable if you botch up at that point, and that you accept the consequences.)

        Makeshifts last the longest.

(jeffa) Re: Can't localize lexical variable $var at...
by jeffa (Bishop) on Jun 09, 2002 at 19:12 UTC
    local is baad, m'kay?

    Seriously, as the others have pointed out, you don't need it. Consider our instead:

    perl -lwe "my $var='qq';{our $var=2;print $var;}print $var"
    perl -lwe "our $var='qq';{my $var=2;print $var;}print $var"


    (the triplet paradiddle with high-hat)
Re: Can't localize lexical variable $var at...
by Aristotle (Chancellor) on Jun 10, 2002 at 13:57 UTC
    You know. Maybe what you're looking for is this?
    $ perl -lwe 'my $var="qq";{my $var=2;print $var;}print $var' 2 qq
    Makeshifts last the longest.
      Just as simple as I can ever imagine!
      I knew there should be a way, and a simple one!
      I wish I can use it...
      You know, I'm such a lousy typist
      hhhehehehehe... hehehehe.... :)

      Courage, the Cowardly Dog.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://172935]
Approved by mrbbking
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2017-11-23 21:38 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (340 votes). Check out past polls.