So, lets try this again. When do the dereferencing and autovivication occur? Do they happen first and then the autovivified version is passed to 'exists'? Or does it happen after the parameter is passed to 'exists'?

If the former then my entire question was off-base. If the latter, then in the OP I was asking why it was implemented this way.

I like your idea about an "exists context" -- that certainly seems appropriate. Though I'm guessing that may be hard to implement?

Anyway, thanks for putting up with my poorly worded questions and thanks for the answers!

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.

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

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!!

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.

- tye