When do the dereferencing and autovivication occur?

Autvivification occurs any time you use a variable whose value is undef as a hash or array reference in a lookup or assignment statement. Simple example:

>perl -e"my $x=undef; $y++ if $x->{foo}; print $x"
HASH(0x15d56e0)
[download]

Notice how the if $x->{foo} autovivified $x into a hash reference. When you have a multiple key lookup this rule applies to each value in turn until you get to the last lookup.

This behaviour is very powerful and is used all the time in perl. About the only thing you need to keep in mind, is when doing a lookup where you care about autoviv you have to check each value for undef first. Iow:

if ($x and $x->{foo} and $x->{foo}{bar} and exists $x->{foo}{bar}{baz}
+) {
}
[download]

It doesn't take long to get used to working with complex perl variables and to learn strategies that minimize how often you need to do stuff like this, with experienced perl programmers only rarely having to do so.

Thanks, but again we are tripping over semantics. I get how autovivication works, etc. I am just wondering what has higher precedence in the interpreter.

So, using my original example . . .

next LASTLOG unless exists $user_by_uid{$uid}->{$host};
[download]

. . . what does 'exists' receive? Has $user_by_uid{$uid} already been autovivified? Or does it get autovivified within the code for 'exists'? Or some intermediate phase (e.g. code that handles passing parameters to subroutines)? Where "code" refers to the code used to implement perl.

Update: Wanted to add that I apologize for any confusion. I just find it curious that in the process of testing if something exists something may be created. It seems very counter-intuitive (even if it does make sense in the broader context of dereferencing and autovivication).

And Happy New Year!!

Exists checks to see that the lookup of $var->{$key} is successful, meaning that $key has been used to store a value in the hash prior to the check. Thus we have:

# $user_by_uid{$uid}->{$host}
$var= $user_by_uid{$uid}
$key= $host
[download]

What this means is that if the result of $user_by_uid{$uid} is undef (either by having an explicit undef value or by not being in the %user_by_uid hash at all) then it is autovivified. If there is a hash reference stored in $user_by_uid{$uid} (either intentionally or via autoviv) then the it is checked to see if $host had ever been used as a key.

Tring to reduce this to a one liner: exists checks the the last hash lookup you feed it, not if the full "path" through the data structure exists. This is more obvious if you consider $user_by_id[$uid]->{$host}, obviously exists doesnt operate on arrays, and we get no error, so it means that only ->{$host} part is relevent to exists.

You could always write a simple routine:

sub my_exists {
  my ($hash_ref,$key)= @_;
  return $hash_ref and exists $hash_ref->{$key}
}
[download]

which would not autovivify. Compare it to how the real thing *might* be coded. Im pretty sure this actually wont work due to some subtleties of hash lookups and lvalue arguments but its pretty close to the real thing.

sub my_fake_exists {
  my ($hash_ref,$key)=@_;
  $hash_ref={} if not defined $hash_ref; #fake autoviv
  return exists $hash_ref->{$key}; # do the lookup
}
[download]

---
$world=~s/war/peace/g

As I noted in my reply, the way to make it happen is to give op-nodes the option of refusing to autovivifying. "exists EXPR" gets generated into a (sub)tree of op-nodes the root of which does the "exists" part. So the implementation would cause the compilation into op-nodes to treat "exists EXPR" like it was "do { no autovivify; exists EXPR }" (but, no, it wouldn't be implemented like a source filter).

Of course, the easiest way to implement "no autovivify" is to make attempts to autovivify fatal errors so the easy implementation would actually have to interpret "exists EXPR" as "eval { no autovivify; exists EXPR }", which adds a run-time overhead (and the C code that implements it would need to only "catch" fatal errors due to refusal to autovivify).

So implementing "no autovifiy" makes sense as a first step, especially since I consider it more useful than a magical exists. That requires defining a new lexically scoped "hint" bit and finding all places in the Perl source code that implement auto-vivification and teaching them to obey that bit.