http://www.perlmonks.org?node_id=172938


in reply to Can't localize lexical variable $var at...

That's because...

...you 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.

Replies are listed 'Best First'.
Re: Can't localize lexical variable $var at...
by Abigail-II (Bishop) on Jun 10, 2002 at 13:36 UTC
    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.

    Abigail

Re: Re: Can't localize lexical variable $var at...
by Courage (Parson) on Jun 09, 2002 at 19:17 UTC
    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.

        You did not understood what I meant.
        { my $var=2; sub inc {return $var++} sub dec {return $var--} } print inc; print dec;
        Those subs see that $var which is not seen outside that block, and perl doc says this is a trick to have private static variables.

        Courage, the Cowardly Dog.