in reply to Regex Capturing: Is this a bug or a feature?

I've always interpreted it like this. Since the documentation says it's localized to the current scope -- and not that it's localized upon a match -- then it's the same variable in the whole block. My Perl interpretation of this is:
{ # localize the variables # the block }
E.g.
{ local ($1, $2) = ($1, $2); # OK, so you can't actually write this. # The hacky can write local (*1, *2) = \($1, $2); instead. # Your loop: foreach my $symbol (@syms){ local $test; $symbol=~m/(\w+)\.(\d+)/; print "symbol: $symbol\t\$1: $1\t\$2:$2\n"; print "test is ",$test++,"\n"; my ($ts,$te) = ($1,$2); } }
Cheers,
-Anomo

Replies are listed 'Best First'.
Re: Re: Regex Capturing: Is this a bug or a feature?
by shotgunefx (Parson) on Sep 28, 2002 at 21:31 UTC
    While your interpretation happens to match the way it works, why would you interpret it being scoped to the outer block? It's declared in the foreach's block.

    If you go by perlre saying "are all dynamically scoped until the end of the enclosing block ", I interpret that as the foreach's block as that is the enclosing block in this example.

    I just wish it was better documented so I could have slept 10 hours instead of banging my head of the wall.

    -Lee

    "To be civilized is to deny one's nature."
      Why would you interperate it being scoped to the outer block?

      I'd like to change "the outher block" to "an outer (imaginary) block". The outer block I used above isn't written by the coder.

      It's declared in the foreach's block

      What's declared in that block? Something is declared for the block rather than in it.

      I interperate that as the foreach's block as that is the enclosing block in this example.

      Effectively that's the same thing as the end of the imaginary block.

      I thought it would be clear that everything but your code was "added" by Perl, especially since I wrote my own $DIGIT localizer.

      Hope this makes it more clear what I meant.

      Cheers,
      -Anomo
        I'd like to change "the outher block" to "an outer (imaginary) block". The outer block I used above isn't written by the coder.

        Seems a funky way to state it, but what I think you're getting at is that if a local variable isn't declared within any existing block, then it will treat the current file as a block.

        While it is true that the compilation unit itself (as in file or eval statement) can be the scope of a my'd (lexical) or local (dynamic) variable, that's not what's going on here.

        What's declared in that block? Something is declared for the block rather than in it.

        The first opening curly brace to the closing curly brace of a "for" loop is a block. Same thing with "foreach"... (for/foreach are synonyms)
        foreach $element @array {#code}
        Perfectly valid block...

        Finally, what's wrong with this: local ($1, $2) = ($1, $2); # OK, so you can't actually write this. Try it... It works.
        What you can't do is this:
        $1 = 50;
        With warnings turned on you'll get something along the lines of a "modification of read-only value at line x". Update: Forget the warnings thing... $1 = 50; is a flat out compilation error
        "Effectively that's the same thing as the end of the imaginary block. "

        To be honest, I am confused by this. Doesn't the foreach block constitute it's own scope? I would interpret it like so...
        { # Your loop: foreach my $symbol (@syms){ local ($1, $2) = ($1, $2); # OK, so you can't actually local $test; $symbol=~m/(\w+)\.(\d+)/; print "symbol: $symbol\t\$1: $1\t\$2:$2\n"; print "test is ",$test++,"\n"; my ($ts,$te) = ($1,$2); } }
        which is what I'd expect from local() scoping. I understand it's the regex engine so I don't have a problem with it not working the same way. I do think the documentation is very confusing and reminds me of my $x if 0 "feature"

        -Lee

        "To be civilized is to deny one's nature."