Re^4: In place search and replace with a hash

[LanX]

You missed the point. Imho RHS of s/// isn't evaluated w/o e flag.

[Athanasius]

13:25 >perl -wE "my %h = (x => 0, '$1' => 1); my $s = 'axb'; say $s =~
+ s/(x)/$h{$1}/r; say $s =~ s/(x)/$h{'$1'}/r;"
a0b
a1b

13:27 >

?

[LanX]

> ?

Well AnoMonk said "single quotes ... prevent variable interpolation" that's misleading.

update

maybe clearer with an example

  DB<106> %h = (x => 0, '$1' => 1);
 => ("x", 0, "\$1", 1)

  DB<107> $s = 'axb'
 => "axb"

  DB<108> $s =~ s/(x)/'$1'/r;             # no prevention
 => "a'x'b"

single quotes on the RHS of s/// never prevent interpolation.

Interpolation is the process to translate "$a $h{$b}" to $a . " " . $h{$b} at compile time.

But the keys of a hash-fetch are not interpolated they are executed, otherwise something like $h{$a$b} wouldn't cause a syntax error.

[Athanasius]

OK, I take your point. Scalar interpolation is a narrower concept than I had thought. I assumed it meant replacing a variable name with its value, but perlglossary defines it as:

The insertion of a scalar ... value somewhere in the middle of another value, such that it appears to have been there all along. In Perl, variable interpolation happens in double-quoted strings and patterns, ...

And in perlop I found:

Interpolated scalars and arrays are converted internally to the join and . catenation operations. Thus, "$foo XXX '@arr'" becomes:

  $foo . " XXX '" . (join $", @arr) . "'";

I hadn’t thought about it that way before.

So, you’re correct in that:

1. The RHS of a substitution is interpolated, and single quotes do not suppress this (unless they are used as the delimiter).

2. The key field in a hash lookup $hash{ ... } is not automatically interpolated, since if it were, $h{$a$b} would be parsed as $h{$a.$b}.

Of course it is the case that an unquoted bareword is automatically stringified under certain conditions: $h{abc} is OK, but $h{2de} and $h{f g} are syntax errors. In fact, it looks as though the rules for stringifying a hash lookup key are the same as for stringifying the LHS of the => operator:

The => operator is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores.
— Comma Operator

But when you say:

But the keys of a hash-fetch are not interpolated they are executed, ...

I don’t think “executed” is the right term here: it sounds like you are saying they are evaled, which of course they are not. I would say rather: they are implicitly stringified (providing they meet the criteria detailed above) unless they have already been explicitly stringified, either by double-quotes ("..." or qq[...]) or by concatenation.

Thanks for raising some interesting distinctions.

[Anonymous Monk]

Okay, the correct word is 'parsed'... I think :)