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

Case 4 is in fact identical to case 3, since $v in both cases is already a 'my' variable, subject to lexical scoping.

Replies are listed 'Best First'.
Re^4: Hard syntax error or disambiguable parsing?
by ack (Deacon) on Jan 29, 2009 at 16:44 UTC

    Case 4 is in fact identical to case 3, since $v in both cases is already a 'my' variable, subject to lexical scoping.

    That doesn't make sense to me. If anything, if I understand the documentation, Case 2 and 3 are almost identical and Cases 1 and 4 are almost identical.

    In Cases 1 and 2, there is no indication about whether the outer, enclosing scope (outside of the scope of the foreach loop) there is any variable $v wandering around. Since it is not shown, I would presume that the intent is that no such varible exists in exterior scope(s). And I'm not sure that it really matters, in the context of what I'm thinking.

    But, if I understand the documentation, in Cases 1 and 4, the use of my in the creation of the loop variable results in a lexically scoped variable and it never appears in any package symbol table.

    However, in the situations in Cases 2 and 3, the loop variable is created as if it were created with a local construct. In which case the $v exists in the package symbol table, but a copy is created and used within the scope of the loop and the original value of $v is not touched. At the end of the loop's scope, the original value of $v is restored to the variable in the package symbol table.

    So the difference, it seems to me, is whether the package symbol table's variables (symbols?) are used or a new, unseen (by the package symbol table) variable (symbol?) are created for the duration of the loop's scope.

    For me, that would seem to make Cases 2 & 3 almost identical and Cases 1 & 4 almost identical.

    But then, I'm still learning and could be wrong.

    ack Albuquerque, NM

      Cases 1, 3 and 4 are almost identical wrt the scoping rules applied to the loop variable. Case 1 differs to the others only in that the lexical variable $v doesn't exist before the perl compiler sees the loop (so I guess that $v will be allocated in that scope's scratchpad.)

      Case 2 is the only different one wrt to scoping - depending on whether $v has been declared outside the scope in which the foreach occurs at all, or declared as my, or as our:

      • if it hasn't been declared, $v will mask a package variable,
      • which is also the case if $v has been declared with our;
      • if it has been declared with my, the loop variable will be aliasing that $v, and lexically scoped - in that case, the scoping rules are identical to 1, 3 and 4.

      See also Re^6: 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?