At 04:28 PM 8/2/2002 +0200, Haegl wrote:
>On 2002/08/02 16:11:26 Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> >It does on reading. I forget the eloquent explanation about the how or
> >why, but all references bar the leftmost are vivified. (Even inside
> >defined). In effect, all bar the last reference are in lvalue context -
> >only the rightmost is rvalue.
>
>The explanation is the part that would have been the most interesting...
>Everyone: Is this just some unwanted but unavoidable behaviour that
>results from the lvalue/rvalue processing or is there a real reason
>behind it? (I don't see one, that's why I ask :-)
IIRC, it's basically because Perl5 doesn't have multidimensional keys,
so $a[0]{"foo"}[24] becomes (in pseudo-perl5-assembler, assume each
op pops its args and pushes its results)
push $a
array_fetch 0
hash_fetch "foo"
array_fetch 24
So, in order that it not segfault in the middle by trying to do a fetch out of
a NULL hash or array, the first to fetches are called in lvalue context (or
rather,
"this element must exist - create it if you have to" context). With
multidimensional
keys, Perl6 can avoid this trap, but we really still need an lvalue fetch -
one reason
being references. We need to support
$a = \@b[2];
$$a = 4;
which only does a fetch on @b[2], but @b[2] had better autovivify, or the
deref may
segfault.
-- BKS
