Re: PerlHash.get_pmc_keyed of non existing key

[Gordon Henriksen]

On Saturday, August 23, 2003, at 10:37 , Luke Palmer wrote:

Gordon Henriksen writes:
Taking a thread from Perl 6 Internals. Will Perl 6 support this 
behavior?

        $ perl <<'EOT'
                my @ary;
                my $ref = \$ary[0];
                $$ref = "value";
                print '$ary[0] : ', $ary[0], "\n";
        EOT
        $ary[0] : value
Presumably the Perl 6 would be:

        my @ary;
        my $ref = [EMAIL PROTECTED];
        $$ref = "value";
        print '@ary[0] : ', @ary[0], "\n";   # -> @ary[0] : value
That has to do with autovivification semantics.  Particularly, do 
things autovivify when you take a nonconstant reference to them.  I 
think they should, and that wasn't one of those cases where autovivi 
was broken, so it probably will.
Exactly what I was arguing on p6i—autovivify in lvalue context, but not 
in rvalue context. i.e., both of these programs should work as specified 
in comments:

        my @ary;
        my $ref = [EMAIL PROTECTED];
        $$ref = "value";
        print '@ary[0] : ', @ary[0], "\n";
        # @ary[0] : value
        my %hash = { a => 1, b => 2 };
        my $temp = %hash{c};
        print exists %hash{c}? "exists\n" : "DNE\n";
        # DNE
And this?

        my @cows of Cow:
        my @cats of Cat;
        my $ref = [EMAIL PROTECTED];
        @cats[0] := $$ref;
        @cats[1] := @cows[0];   # Just to hammer the point home....
        $$ref = new Dog;
I would assume that's also an error.  @cats C<returns Cat> [1], and if 
you bind part of it to something that returns a non-cat, there should 
be an exception... or a compile error.
This particular example would be catchable at compile-time, ideally—it 
would require type inference, but it's catchable at compile time. But in 
the general case? Where the array, or the reference, or both are untyped 
and passed in from someplace else, their types/constraints not knowable 
until runtime? Where would the exception throw?

Throw here, at bind time?

	@cats[0] := $$ref;

The undef value would need to know about its container (or, more 
appropriately:) said container's constraints. But undef is still 
compatible with both containers. To expand on that, what about this case?

        my @listA is any (Cow | Cat);
        my @listB is any (Cat | Dog);
        @listA[0] := @listB[0];
Author could expect a Cat to be compatible and for the code to run. But 
very action-at-a-distance-ey if it did work.

Or throw here, at assign time?

	$$ref = new Dog;

The undef PMC would need to know about all of its containers and all of 
their constraints. Yuck! With weak references, too, because @cows could 
be GC'd while @cats remained valid.

—

Gordon Henriksen
[EMAIL PROTECTED]