"Deven T. Corzine" wrote:
>
> On Sat, 23 Dec 2000, Graham Barr wrote:
>
> > This has been discussed on p5p many many times. And many times
> > I have agreed with what you wrote. However one thing you did not mention,
> > but does need to be considered is
> >
> > func($x{1}{2}{3})
> >
> > at this point you do not know if this is a read or write access as
> > the sub could do $_[0] = 'fred'. If this can be handled in someway
> > so that the autoviv does not happen until the assignment then OK,
> > but otherwise I think we would have to stick with perl5 semantics
>
> This is a good point. Similar arguments apply to grep, map, foreach, etc.
> Could we have some sort of "lazy evaluation" mode for lvalues where a
> reference to an undefined substructure sets a flag and saves the expression
> for the lvalue, returning undef whenever evaluated in a read-only context
> and autovivifying when necessary to write to the lvalue?
>
> Deven
Lazy autovivification could work by adding an on-assignment magic to
the previously nonexistent SV, which details the creation of the intervening
structures.
This will have to chain: What if &func defers the question
of read or write to another layer down? An addition of a magic, so that
values in previously undefined structures evaluate as undef but will create
interveners as needed if and when they are assigned to (even if it is an
assignment of undef) would work.
The magic would have to consult the appropriate symbol tables when it runs,
to avoid problems of two magics getting set up referring to the same nonexistent
structure:
$first = \($$$hash{one}{two}{three}); # a reference to an undefined
# scalar, with write-magic
$second = \($$$hash{one}{two}{four}); # undef with very similar write-magic
$$first = "first";
$$second = 2; # magic runs but doesn't do anything since
# %{$$hash{one}{two}} got vivified already.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"Live fast, die young, and leave a beautiful corpse"
