in reply to Re^5: Hard syntax error or disambiguable parsing?
in thread Hard syntax error or disambiguable parsing?

if it has been declared with my, the loop variable will be aliasing that $v, and lexically scoped

What, exactly, does 'aliasing that $v' mean?

I expect it means the same thing as 'it uses that variable instead of the global one' in the following extract from perlsyn, but I don't know what that means either.

If the variable was previously declared with my, it uses that variable instead of the global one, but it's still localized to the loop.

I thought I knew what it meant but the examples here prove that my (mis-)understanding was wrong. What is the significance of it using that variable? When does it make a difference?

Based on the examples here, it seems as if perlsyn could (maybe should) be rewritten to say:

If the variable was previously declared with my then the variable is implicitly lexically scoped, and is therefore visible only within the loop.

Does this make sense? Is it correct? Or am I still ignorant and confused?

  • Comment on Re^6: Hard syntax error or disambiguable parsing?

Replies are listed 'Best First'.
Re^7: Hard syntax error or disambiguable parsing?
by BrowserUk (Patriarch) on Jan 30, 2009 at 02:54 UTC

    I think the way it came about it that the foreach version of for each requires that the loop variable be aliased to the items in the list, and (at least historically) Perl's aliasing is achieved through globs.

    So, pre-lexicals, the localisation was done by doing local *loopvar; under the covers.

    Once lexicals came to pass, the quick fix for dealing with aliasing a lexical was to do the (rough?) equivalent of:

    $_ = 'fred'; my $i = 123; { local *_ = \$i; for $i ( 1 .. 5 ) { print $i; } } print "\$_:$_ \$i:$i" 1 2 3 4 5 $_:fred $i:123

    Which use *_ as the glob (per an implicit loop var loop), but allows the programmer to refer to the temporary variable by name within the loop body, whilst ensuring that both *_ and $i get restored afterward.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      So, pre-lexicals, the localisation was done by doing local *loopvar; under the covers.

      Since *loopvar is localised, not $loopvar, does this mean that in

      our @loopvar; foreach $loopvar (...) { ... }
      I can not access the outer @loopvar, because it is masked then too?

      -- 
      Ronald Fischer <ynnor@mm.st>

        My knowledge of Perl doesn't go back to pre-lexical days, so I don't know for sure, but I doubt it. Maybe that should be local $loopvar;?

        As I thought I made clear, I'm just trying to interpret what I see in code and comments to piece together a possible scenario for how the current situation came about. Ie. It's all supposition and sourcecode forensics founded upon my inability to see any reasoning by which it would have been explicitely architected to operate this way.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I can not access the outer @loopvar, because it is masked then too?

        Try it ;-) But no, the @loopvar isn't masked, only the SCALAR slot in the typeglob gets a new reference.

Re^7: Hard syntax error or disambiguable parsing?
by shmem (Chancellor) on Jan 30, 2009 at 13:59 UTC

    There's surely somebody out there, who wrote the code, and could explain it better... ;-)

    Aliasing means, that the carcass of the variable is retained (its content saved to be restored later) and filled with a new structure, i.e. it gets a new pointer. Let's have a look. Loop with a symbol table variable:

    perl -MDevel::Peek -le 'our $f = 42; Dump *f{SCALAR}; for $f (2) { Dum +p *f{SCALAR} }' SV = RV(0x8664670) at 0x863bc28 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x863c7bc SV = IV(0x8657eec) at 0x863c7bc REFCNT = 2 FLAGS = (IOK,pIOK) IV = 42 SV = RV(0x8664670) at 0x863be2c REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x863c7ec SV = IV(0x8657ee8) at 0x863c7ec REFCNT = 3 FLAGS = (PADBUSY,PADTMP,IOK,READONLY,pIOK) IV = 2

    Note that the scalar variable (SV) contains the same reference value (RV(0x8664670)) outside and inside the loop. It's content however is allocated at a different memory location:

    SV = RV(0x8664670) at 0x863bc28 # outside SV = RV(0x8664670) at 0x863be2c # inside

    That's essentially the same for my variables.

    perl -MDevel::Peek -le 'my $f = 42; Dump \$f; for $f (2) { Dump \$f } +for my $f (2) { Dump \$f }' SV = RV(0x9d1a678) at 0x9cf1c28 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x9cf1cdc SV = IV(0x9d0def8) at 0x9cf1cdc REFCNT = 2 FLAGS = (PADBUSY,PADMY,IOK,pIOK) IV = 42 SV = RV(0x9d1a678) at 0x9cf1e2c REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x9cf1c28 SV = IV(0x9d0defc) at 0x9cf1c28 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 2 SV = RV(0x9d1a678) at 0x9cf1c28 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x9cf1e2c SV = IV(0x9d0defc) at 0x9cf1e2c REFCNT = 1 FLAGS = (IOK,pIOK) IV = 2

    Here we have three different storage locations, because the two loops have each its own scope:

    SV = RV(0x9d1a678) at 0x9cf1c28 SV = RV(0x9d1a678) at 0x9cf1e2c SV = RV(0x9d1a678) at 0x9cf1c28

    The RV(0x9d1a678) is the same, which shows us that the following for loops are aliasing the same $f :

    my $f; for $f (1..3) { } for my $f (1..3) { }

    In the perl sources, you'll find the relevant code which sets up the loop variable at Perl_newFOROP() in file op.c, and the "aliasing code" in pp_ctl.c at PP(pp_enteriter).

    update: corrected code locations

Re^7: Hard syntax error or disambiguable parsing?
by gone2015 (Deacon) on Jan 30, 2009 at 11:09 UTC
    What, exactly, does 'aliasing that $v' mean?

    This may not be what you're asking, but... the mechanics of "aliasing" fall out of the way Perl manages values.

    The name $s refers to a pointer to the value currently associated with that name. The array entry for $a[78] also refers to a pointer to the value currently associated with the entry. And so on. All values are accessed via one level of indirection.

    To make $v into an alias for some array entry, Perl simply copies the array entry's pointer to $v's pointer... shazzam ! (Which would probably be curtains for the old value associated with $v, "garbage collection"-wise; but that's another story.)

    Problem is clearly that on loop exit, left to its own devices, the loop variable would remain an alias -- aliases are magic enough when contained within the scope of the loop !

    I now speculate: I suspect that the $v doesn't know it's an alias, the mechanism is so deeply buried in the way variables work -- but in any case, extra code would be required to copy the last value to $v. Besides, much of the time it's useful to have a local loop variable, and since that mechanism already existed my guess would be that looked like the simplest approach...

    What is the significance of it using that variable? When does it make a difference?

    The difference is that if there is a Global and a Lexical $i in existence at the same time, then it is the Lexical that is localized for the duration of the loop. As this illustrates:

    use strict ; use warnings ; use vars '$i' ; $i = 'hello there' ; for $i (1..2) { print "$i: $main::i\n" ; # 1: 1 } ; # 2: 2 print "$i\n" ; # hello there for my $i (4..5) { print "$i: $main::i\n" ; # 4: hello there } ; # 5: hello there print "$i\n" ; # hello there my $i = '*' ; for $i (7..8) { print "$i: $main::i\n" ; # 7: hello there } ; # 8: hello there print "$i: $main::i\n" ; # *: hello there
    I suppose it might have been clearer if my at the package layer declared package variables... but that horse left home at some speed many, many moons ago.