Can the autovivication behavior be changed slightly for Perl 6?

Specificly, can we suppress autovivication in read-only circumstances, and 
evaluate the expression as "undef" immediately instead of autovivicating
empty data structures that didn't exist before?

The current behavior in Perl 5 is inconsistent.  Attempting to reference a
hash or array element doesn't normally cause that element to spring into
existence, but attempting to reference substructures DOES suddenly cause
that substructure to spring into existence.  This behavior is desirable
when writing to that substructure, but undesirable when reading from it,
and inconsistent with the normal behavior of single-level perl structures.

Referencing a nonexistent entry in a hash or array doesn't create that
entry UNLESS it's autovivified as a reference.  "%x = (); $x{1};" does NOT
have the same effect as "%x = (1 => undef);"; why does "%x = (); $x{1}{1};"
have the same effect as "%x = (1 => {});"?  If the programmer has never
stored any values into %x, it would be reasonable to expect it to remain
empty; why violate this reasonable expectation just because of an attempted
reference to a nonexistent structure?

Here is an example (in the Perl debugger) demonstrating this inconsistency:

  DB<1> x \%x                           # %x starts empty
0  HASH(0x82136d0)
     empty hash
  DB<2> x $x{1}                         # access a nonexistent entry
0  undef
  DB<3> x \%x                           # %x remains empty
0  HASH(0x82136d0)
     empty hash
  DB<4> x $x{1}{2}{3}{4}                # access nonexistent substructures
0  undef
  DB<5> x \%x                           # %x no longer empty!
0  HASH(0x82136d0)
   1 => HASH(0x829a33c)
      2 => HASH(0x829a378)
         3 => HASH(0x829a408)
              empty hash
  DB<6> x \@x                           # @x also starts empty
0  ARRAY(0x829a420)
     empty array
  DB<7> x $x[3]                         # access a nonexistent entry
0  undef
  DB<8> x \@x                           # @x remains empty
0  ARRAY(0x829a420)
     empty array
  DB<9> x $x[3][4]                      # access nonexistent substructure
0  undef
  DB<10> x \@x                          # @x no longer empty!
0  ARRAY(0x829a420)
   0  undef
   1  undef
   2  undef
   3  ARRAY(0x829a554)
        empty array

Now, I understand why this happens, but is it really a good thing that it
happens in the first?  We're not storing into the nonexistent substructures
(in which case you DO want autovivification, of course), only attempting to
access a possible value in a substructure that may not exist.  This access
attempt is creating the intervening substructures, despite appearing to be
a "read-only" operation on the data structure it modifies.  (This would be
closely analogous to having Unix create intervening directories for a
nonexistent pathname before reporting a "No such file or directory" error 
for the full pathname...)

Currently, it's sometimes necessary to do "defined" tests on intermediate
levels to workaround this behavior before testing inside substructures that
may not exist.

Couldn't we change this for Perl 6?

Deven

Reply via email to