Re^2: Hard syntax error or disambiguable parsing?

A foreach loop absolutely wants to create a new local scalar variable

Somehow I forgot about the scoping rules within foreach, so I reread perlsyn:

The "foreach" loop iterates over a normal list value and sets the variable VAR to be each element of the list in turn. If the variable is preceded with the keyword "my", then it is lexically scoped, and is therefore visible only within the loop. Otherwise, the variable is implicitly local to the loop and regains its former value upon exiting the loop. 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.

If I understand this right, we have 4 cases:

{ foreach my $v (...) {} } # 1
{ foreach $v (...) {} } # 2
{ my $v; foreach $v (...) {} } # 3 
{ my $v; foreach my $v (...) {} } # 4
[download]

In case 1, $v is a lexical variable where the lifetime ends with the end of the loop. In case 2, $v is in the global symbol table, but localized, in the sense we usually get by local $v;; the localization ends at the end of the loop. As for case 3, I don't really understand the text of the man page; what does localizing a lexical variable mean? As for case 4, the man page doesn't say anything explicitly, so it must be in effect the same as case 1.

Is this correct, and could you please give some explication about case 3?

--
Ronald Fischer <ynnor@mm.st>

Comment on Re^2: Hard syntax error or disambiguable parsing? Select or Download Code

Replies are listed 'Best First'.
Re^3: Hard syntax error or disambiguable parsing? by shmem (Chancellor) on Jan 29, 2009 at 10:43 UTC
Case 4 is in fact identical to case 3, since `$v` in both cases is already a 'my' variable, subject to lexical scoping.	[reply] [d/l]
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	[reply] [d/l] [select]
Re^5: Hard syntax error or disambiguable parsing? by shmem (Chancellor) on Jan 29, 2009 at 21:32 UTC
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?.	[reply] [d/l] [select]
Re^6: Hard syntax error or disambiguable parsing? by ig (Vicar) on Jan 30, 2009 at 00:41 UTC
Re^7: Hard syntax error or disambiguable parsing? by BrowserUk (Patriarch) on Jan 30, 2009 at 02:54 UTC
Some notes below your chosen depth have not been shown here
Re^7: Hard syntax error or disambiguable parsing? by shmem (Chancellor) on Jan 30, 2009 at 13:59 UTC
Re^7: Hard syntax error or disambiguable parsing? by gone2015 (Deacon) on Jan 30, 2009 at 11:09 UTC
Re^3: Hard syntax error or disambiguable parsing? by ack (Deacon) on Jan 29, 2009 at 16:26 UTC
Yet again I learn...and I even read the documentation (I even went back and read what I thought was the full description of this construct). But clearly I did not. rovf's extract actually reminded me of what I had learned for what seems like a long time ago...the difference between my and local in the context of the loop variable. And it is the local at work that made my test code (listed in an earlier thread on this inquiry)...not because, as I mis-stated, the loop variable is automatically lexically scoped (ala, my or an implicit my). Thanks, rovf. Maybe someday I'll be able to keep more of Perl's wonderments straight in my mind. ack Albuquerque, NM	[reply]