http://www.perlmonks.org?node_id=438291


in reply to hash slice

Page 37 gives an example of a hash slice. The important concept to note is that the sigil (the symbol in front of a variable name, like $, @, or %) connotes what kind of value is being retrieved, not what kind of variable is being accessed.

The shape of the braces indicate that @hsh{@ary} is a slice of a hash, rather than a slice of an array, which would be @hsh[@ary].

Applying undef to a hash slice relies on undocumented behavior, but the intent is to get all those keys to exist in the hash. A better technique is

@hsh{@ary} = ();

Caution: Contents may have been coded under pressure.

Replies are listed 'Best First'.
Re^2: hash slice
by dragonchild (Archbishop) on Mar 10, 2005 at 15:40 UTC
    Applying undef to a hash slice relies on undocumented behavior, . . .

    It's not undocumented behavior. It's just behavior that's documented in a different place, unrelated to hashslices. Basically, undef is a keyword that takes an array. @hsh{@ary} evaluates to an array. But, to do that, Perl needs to autovivify all the slots in the hash in order to return the values. Heck, anything that takes a list will do.

    undef @hsh{@ary}; chomp @hsh{@ary}; chop @hsh{@ary}; map $_, @hsh{@ary}; 1 foreach @hsh{@ary};

    Those will all do the trick. The undef is a no-op to provide something that requires evaluation of a list.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      Basically, undef is a keyword that takes an array.
      Yes, but a slice is not an array, and undef is explicitly not a listop.

      undef

      Undefines the value of EXPR, which must be an lvalue. Use only on a scalar value, an array (using @ ), a hash (using % ), a subroutine (using & ), or a typeglob (using * ). ... Note that this is a unary operator, not a list operator.
      What happens when you undef a slice is that it is converted into a list, which is then evaluated in scalar context, which yields the last element of the slice as the scalar value. That value (and only that value) is then set to undef (so it's not a no-op; if you want a no-op use the \ operator, which will take a list). Contrast that with handing it an array proper. The entire array is then undefined.

      The conversion from hash slice to list to scalar is not documented, and should generate a warning. In fact, if you try to pass undef a list of array elements, you will get an error.

      there is no such thing as a list in scalar context


      Caution: Contents may have been coded under pressure.

        I thought that seeing it on my screen would make it easier to understand. I'm missing something here. I was kind of expecting the array to be unchanged ... but that's not what happened:

        $ perl -MData::Dumper -e '@x=0..10; undef @x[2..7]; print Dumper(\@x)' $VAR1 = [ 0, 1, 2, 3, 4, 5, 6, undef, 8, 9, 10 ];

        Obviously, if undef worked as is otherwise expected, all numbers from 2 through 7 would be undef. What surprised me here is that 7 still is undef'd. Something funky is happening.

        Not that I'd ever have this problem in production code - I don't ever have the need for this type of behaviour (undefing a slice)... and would have thought about using @x[2..7] = () first anyway.

        Update: Yeah, Roy Johnson explained it - I see that now. However, it's still a bit buried, and Roy Johnson's lengthier explanation below is much clearer. Thanks, Roy!