in reply to Lexical scope vs. postfix loops (perl bug?)

Using statement modifiers on a my declaration results in undefined behaviour. So the answer is "don't do that" ;-) (see perlsyn)

"Undefined" means, as always, that anything can happen. The "do { my $x = ... } for (1 .. 3)" version is not such a case (the modifier is on do, not my), so that's why it behaves reasonably.

Replies are listed 'Best First'.
Re^2: Lexical scope vs. postfix loops (perl bug?)
by jh (Beadle) on Aug 25, 2008 at 20:27 UTC
    I see!

    Do you know why a specific behavior is not defined? Just curious.

    I also note that the warning appears in the perlsyn page 5.10, but not in my perlsyn page (5.8). Is this something that bit people until they added it to the manual? I didn't see it in the camel either...

    Anyway, thanks for the help.

[reply]

      Do you know why a specific behavior is not defined? Just curious.

      The behaviour is actually quite predictable, but it's probably not one the Perl developers want to be held to. If that's the case, the warning in the documentation serves to avoid a dependancy on the current behaviour.

      In case you're curious,

      The current compile-time behaviour of my is to define the variable for the rest of the scope, starting with the next statement.

      The current run-time behaviour of my is to place an instruction on the stack to clear (if refcount = 0) or replace (if refcount > 0) the variable on scope exit. It also returns the variable as an lvalue.

[reply]
[d/l]
[select]
      Do you know why a specific behavior is not defined?
      I think that there's no one consistent way to define one. Usually variables are block scoped, so making my $x for @list behaving the same as do { my $x } for @list is just weird.

      One could argue that $stuff for @list should always be the same as for @list { $stuff }, but then you could write 

      use strict;
print $x*$x for my $x (0..10);

      [download]

      Which seems equally weird, because a variable is used (textually)before it is declared. (And I don't know if that's technically possible in the perl compiler).

      So regardless from which angle you look at it, it smells badly. So the behaviour is not defined. Maybe someday a hero of programming languages will find something that's consistent in every way, and then it can be still implemented.

[reply]
[d/l]
[select]
        I could live with a hero of perl who makes statements like this emit a warning if 'use warnings' is on.
[reply]
        I think that there's no one consistent way to define one. Usually variables are block scoped, so making my $x for @list behaving the same as do { my $x } for @list is just weird.
        Do you really think that it's weirder than having for my $x ( @list ) { BLOCK } behave the same as { my $x; for $x ( @list ) { BLOCK } }?
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom