Jonathan Worthington wrote:
> In the latter case, it's fairly clear how these differ:
> @x = 1;
> @x := 1;
> In the first, we look up the container in slot 0 or the array and assign a 1
> into it. In the second, we bind a 1 directly into the slot. There's no
> container any more (so any future assignment attempts will fail, for
I'll have to beg to differ. My understanding of it is as follows: the
first case works as you describe. The second case differs, though,
because there is no way to bind a variable directly to a value;
variables can only be bound to containers. So the interpreter creates
a new item container, assigns "1" to it, and binds the zero slot to
it. Mind you: when the optimizer gets its hands on this, it'll
probably just simplify it to the first case, as the two are
functionally equivalent. The distinction only really matters when
you're binding to an already-existing container (e.g., "@x = $foo"
vs. "@x := $foo").
> With packed arrays, however, I'm less clear what they mean. Since the point
> of a packed array is compact storage, there's no chance to actually have
> containers. Thus does assignment to a slot in a compact array ever make
> sense? There's not a container to look up and store things in.
Assignment makes perfect sense: the compact storage is the container
(which is bound to @x), and you assign a value to a slot in that
container. What doesn't make sense is binding a slot of a packed
array to some other container:
@x := $foo; # this should die.
The only way I can see this working is if perl first converts the
packed array into a normal array, and then binds slot 0 to $foo.
Jonathan "Dataweaver" Lang