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"
[download]

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.

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) . "'";
[download]

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.

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

> 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 originally wrote "evaled" and changed it to avoid confusion with string eval.

But actually it is first evaled¹ and then of course stringified.

It's a subexpression returning a value, even within interpolation:

  DB<119> %h=(1=>42)
 => (1, 42)

  DB<120> $a=2
 => 2

  DB<121> "<<< $h{3-$a} >>>"
 => "<<< 42 >>>"
[download]

so 3-$a is of course executed.

> Thanks for raising some interesting distinctions.

I took your "?" as a question. :)

May sound like nitpicking, but I'm convinced Perl's behavior needs a more axiomatic (mathematical) explanation.

Otherwise people rely far to often on try-and-error coding and consequently cargo cult, believing that the interpolation on the RHS of s/// is just one other magic DWIM mechanism.

Even more important if one tries understanding what s///e and s///ee do.

That's why I once wrote:

s/RegEx/substitutions/: Variable interpolation and when to use /e - modifiers

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

¹) think block eval or do

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