>>>>> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> Well, perl5 does already manage to avoid auto-vivifying hash keys
NC> when they are used as subroutine arguments. It uses magic, rather
NC> than dataflow analysis:
NC> sub rval {
NC> my $a = $_[0];
NC> }
NC> sub lval {
NC> $_[0] = undef;
NC> }
NC> sub dumpit {
NC> Dump ($_[0]);
NC> }
NC> my %a = (camel => 2);
NC> rval ($a{llama});
that is only one level deep and perl never autovivified that when
reading. try this with $a{llama}{alpaca}. that will autoviv the 'llama'
level even when reading. i don't think the sub has anything to do with
it. the expression is evaled before the pass by ref is done and the ref
is to the lowest element. so the higher elements must be autovived to
make that work. i know why larry and others want this to change but it
will be tricky as you can't know how this ref will be used later
on. what if you passed \$a{llama}{alpaca}? even as a read only param,
you could deref later through the ref in another sub that gets passed it
from this sub. but how do you pass a ref to hash levels that don't
exist? lazy eval may be one way but then you have to pass a thunk (what
algol called pass by name/code thingys) and eval that at the time of the
deref.
this is a minor can of worms IMO. we can define the language behavior to
not autoviv on reading but how to detect that at runtime is an issue. i
think larry didn't do this in perl5 more because of the implementation
was very hard rather than for the poor choice of semantics.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
