in reply to Re: Getting an unknown error
in thread Getting an unknown error

... use of $1 as a loop variable is ... unusual ...

I was surprised that Perl is quite happy, both with and without full warnings and strictures, with aliasing $1, normally read-only, to a for-loop list, then chomp-ing it, but this is so under the few Perl versions I tried. I guess the alias does the trick.


Give a man a fish:  <%-(-(-(-<

Replies are listed 'Best First'.
Re^3: Getting an unknown error
by ww (Archbishop) on Apr 23, 2015 at 18:14 UTC

    "does the trick ... and could be considered a bug? Well, that, or an error in the docs. I think that p5p or others should consider this.

    Yes, if for no other reason than that many of us believe as did AnomalousMonk ... and in my case, at least, (sometimes-unreliable-) memory tells me I got my notion from some authoritative documentation.

    Quick 'n dirty search lead to this, in discussion of regex vars inside perlvars (which may or may not be where I got the idea that $1 is reserved for regexen... and read_only):
    $<digits> ($1, $2, ...)
    
    Contains the subpattern from the corresponding set of capturing parentheses from the last successful pattern match, not counting patterns matched in nested blocks that have been exited already.
    
    These variables are read-only and dynamically-scoped.
    
    Mnemonic: like \digits.

    From perlvar for 5.20.1, and likewise, in the docs for 5.18.4:

      These variables are read-only and dynamically-scoped.

    I suspect that statement can be found at least back to 5.10 and maybe to 5.8.

    Somewhere here, there's a big Ooops!

      These variables are read-only ...

      I suspect that statement can be found at least back to 5.10 and maybe to 5.8.

      I checked my local perlvar for the versions I have in captivity, 5.8-14, and this assertion is in each one. (I didn't bother to check all the on-line perlvar versions; I assume it's in all those as well.)

      For all my initial shock at seeing an old, dear friend abused in this way, I'm not so sure | I do not think it's classifiable as a bug. After all,  $1 is just a symbol, and aliasing is supposed to enable one to treat one symbol exactly like another. That's what's going on in the for-loop: the perfectly mutable  @line array elements are successively aliased to the  $1 symbol, to which one can do anything it's kosher to do to an element of the array. One can see this here:

      c:\@Work\Perl>perl -wMstrict -le "my @lines = (qq{foo\n}, qq{bar\n}); print qq{[[@lines]]}; ;; for $1 (@lines) { chomp $1; print qq{'$1'}; } ;; print qq{[[@lines]]}; " [[foo bar ]] 'foo' 'bar' [[foo bar]]
      Everything you would expect to happen to  @lines does happen. Similar code that does not alias  $1 still causes the compiler to barf as expected:
      c:\@Work\Perl>perl -wMstrict -le "my @lines = (qq{foo\n}, qq{bar\n}); ;; for my $ln (@lines) { $1 = $ln; chomp $1; print qq{'$1'}; } " Modification of a read-only value attempted at -e line 1.
      So I guess I have to say I'm happy with things as they are. (Update: Some men see things as they are and say "Well... Ok, then!")

      Update: See "alias" in perlglossary.


      Give a man a fish:  <%-(-(-(-<

        Good info. Thanks. In view of that, my second suggestion for action: correction of the docs still seems to be in order, since the current statement is unambiguously incomplete or therefore, inaccurate|incorrect. Maybe, at minimum, an addition to the existing language (to the effect that use involving aliasing is an exception to the "read only") would be in order.

        Thanks to your research, I share the view that there's no reason to tamper with the extant code, but see the current language in perlvar as a "bug in the documentation."



        Quis custodiet ipsos custodes. Juvenal, Satires

        And... check Ln42!