"Within exists" implies it's done by exists. It's not. Perhaps a better term would be "within an exists context", although there's currently no such thing.

I can see how you might interpret it that way, but the last sentence in my previous post clarifies that I was talking about when the events occur. I guess I'm just stumbling over what the correct terminology to use is and I apologize for that.

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

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