This is PerlMonks "Mobile"

Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  


in reply to $1[

It's not easy to understand what your question is, that's why you get fuzzy answers.

> I guess that perl tried to interpret $1[ as element of an array @1?

yes

@1=a..c;

my $a="012210";

$a =~ s/(.)/$1[$1]/g;

print $a;

[download]

abccba

> So I solved this problem in two ways, using ...

Excellent you even solved it, so what is the question again? :)

Your title $1[ is - sorry - really crap, please see How do I compose an effective node title? for inspiration.

And your question is obscured in between lots of regex line noise, please see How do I post a question effectively?

Now the gory details ...

you said in one of your replies

> which looks to me as a bug.

nope, but IMHO it's ...

... flawed by concept:

Normally an identifier in Perl has to match something like /[_a-zA-Z^][_a-zA-Z0-9]*/ but special variables like $\ or $1 are exceptions (see perlvar#SPECIAL-VARIABLES for a list)

They are global symbols and don't need to be declared.

Unfortunately this covers other possible slots of such a symbol, like %hash, @array, $scalar, &code, *glob and probably also filehandle and format....

(see perlmod#Symbol-Tables and perlref#Making-References point 7 for details)

For instance %\ doesn't have any meaning, but since $\ is a special variable, it is

I'd rather prefer that undefined special vars fail under strict, alas, we are talking about a language which supported this concept already in Perl4, i.e. long before it introduced lexicals and strict.

Not a bug

Since this /$array[/ is a parsing error and since 1 is not less a symbol than array it's not a bug.

This is normally not a problem, but regex' tend to become messy.

Cheers Rolf
(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!

Replies are listed 'Best First'.
Re^2: $1[ (or "Does an array @1 exist in Perl ? - Yes!")
by rsFalse (Chaplain) on Oct 11, 2017 at 14:38 UTC
    Then documentation should say that, not only scalar variables with names '\', '1' are valid, but also these names are valid for all structures. Otherwise it is a bug.

    One can use "$1[$2]$3[$4]$5" expecting no array (with impossible names according doc) interpretation.

    Thank you for informative reply and expanding name of a node to better!
[reply]
[d/l]

      The fact that $1 is a pre-declared variable, and that @1 is not does not mean that @1 could not have been a variable, and consequently, that $1[... should not be seen as the beginning of an indexing into the @1 array. It really probably ought to be a strict violation first, since @1 isn't special, but is an identifier, and subject to the rules of parsing that apply to sigil-preceded identifiers when interpolated into a regexp quote-like construct.

      perl -E 'our @array = (1,2,3); *1=\@array; say for @1;'
1
2
3

      [download]

      Here we cheated a little, using the typeglob syntax to create an array by the name of @1. Well, really a symbol for an array named @1, which happens to be an alias to @array in the symbol table. And it is shown to work. With that in mind, there's no reason that m/something$1[.../ should not be seen as the beginning of the indexing into an array element for interpolation within a regexp. Disambiguation can be achieved by wrapping the symbol portion of $1 in curly braces, as in ${1}:

      # $1 will be undef, so not relevant to the pattern. [0] will be a sing
+le-character character class, so matches "0".
perl -E 'our @array = (1,2,3); *1=\@array; say for @1; say "yes" if "0
+" =~ m/.?${1}[0]/;'
1
2
3
yes

      [download]

      Otherwise, this will be variable interpolation:

      # $1[0] is seen as interpolation, placing the value of "1" into the re
+gexp, which matches with the "1" in our target string.
perl -E 'our @array = (1,2,3); *1=\@array; say for @1; say "yes" if "1
+" =~ m/.?$1[0]/;'
1
2
3
yes

      [download]

      The unfortunate part here is that strict appears to be special cased for the numeric-variable symbols rather than specifically for scalars.


      Dave

[reply]
[d/l]
[select]
      One can use "$1[$2]$3[$4]$5" expecting no array (with impossible names according doc) interpretation.

      No, the documentation does not say they are impossible at all:

      Perl variable names may also be a sequence of digits, a single punctuation character, or the two-character sequence: ^ (caret or CIRCUMFLEX ACCENT) followed by any one of the characters [][A-Z^_?\] . These names are all reserved for special uses by Perl; for example, the all-digits names are used to hold data captured by backreferences after a regular expression match.

      So @1, @2, @1066, etc. are all perfectly valid. They are just reserved for special uses by Perl.

[reply]
[d/l]
[select]
        One can reserve @1 , but the parser should croak or at least warn as long as the reservation wasn't filled with meaning.

        I think %+ and %- are good examples of taking advantage of reserved variables after introducing named captures in regex. ( added in Perl v5.10.0)

        @1 has no special meaning and doesn't need to be declared under strict!

        As a side note, it's possible to use @a or %b without explicit declaration under strict ... that's really not optimal and really should be documented.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

[reply]
[d/l]
[select]
      > Then documentation should say that, not only scalar variables with names '\', '1' are valid, but also these names are valid for all structures.

      I agree.

      > Otherwise it is a bug.

      It's a feature! ;]

      Honestly there are many issues with these "open source" docs, and I don't know how to solve them.

      The usual response is "contribute", but the result of more authors is just more confusion.

      We are somehow at the limit of the possibilities of self managed groups. (This observation doesn't only apply for the docs)

      regarding special symbols
      though in this particular case I'd suggest adding a remark to the beginning of perlvar and/or a caveat section at the end, to limit the amount of confusion.

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Je suis Charlie!

[reply]
[d/l]

In Section Seekers of Perl Wisdom