in reply to Re^2: Shouldn't references be readonly?
in thread Shouldn't LITERAL references be readonly? (updated)

Unlike a numeric literal value, [] is compiled into an opcode which calls . . . something (this is where I'm hoping someone more familiar with guts steps in) which returns a new reference value.

$ perl -MO=Concise,-exec, -E '$a = []; $b = 5' 1 <0> enter v 2 <;> nextstate(main 2 -e:1) v:%,us,{,fea=7 3 <0> pushmark s 4 <@> anonlist sK* 5 <#> gvsv[*a] s 6 <2> sassign vKS/2 7 <;> nextstate(main 2 -e:1) v:%,us,{,fea=7 8 <$> const[IV 5] s 9 <#> gvsv[*b] s a <2> sassign vKS/2 b <@> leave[1 ref] vKP/REFC

Opcode 4 here is doing something to allocate a new AV* and pushing the SVrv referencing that new arrayref onto the stack which then is assigned into $a. Opcode 8 is pushing the immediate literal value SViv (which is readonly) onto the stack and assigning that into $b.

Edit: I'm mixing up the layers and perl and C and everything but . . .

When you have map { $_ = 1 } [] in the underlying runtime what's kind of happening is that something's going:

my @args; $args[0] = anonlist();

then when your map EXPR, @args runs, because $_ is aliased to each item in @args something like this happens

$args[0] = 1;

The anonymous arrayref went into the temporary array's slot zero when it was initialized; in the map EXPR you're replacing the value in that slot in the array but you're not doing anything to the arrayref which was referenced by the previous value in that same slot. I admit that it's kind of weird that the temporary arglist slots aren't readonly but if they were made readonly then I don't think aliasing like $a = 1;for($a){ $_ = 'foo' } would work so that $a would have 'foo' afterwards (i.e. aliasing of $_ in for to a transient list of arbitrary values).

Edit 2: while [] is a literal token it doesn't stand for a constant value.

The cake is a lie.
The cake is a lie.
The cake is a lie.