Re^3: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing)

grep (and for) provide lvalue context for their args, since the expectation is that when aliased to $_, the $_ variable (and thus the arg) could be modified by the code in the code block. This lvalue context is what causes the autovivification action to be compiled in. The 'x' element of %$h is created at run-time when the arg list for grep is being assembled, but before grep itself is invoked (i.e. before the code block is called for the first time).

However, function call arguments which are hash subscripts are special-cased. Although function args are technically always in lvalue context (e.g. the sub about to be called might do sub f { $_[0]++ }, who knows!), perl tries to avoid auto-vivification by deferring hash lookup. Instead, if you do foo($h{$k}) then rather than looking up the hash value and passing it as an arg, perl creates a special proxy object (PVLV) which holds pointers to $h and the key and passes that instead. For example:

$ perl -MDevel::Peek -e'sub f { Dump $_[0] } f($h{akey})'
SV = PVLV(0xd28a78) at 0xcb2658
  REFCNT = 1
  FLAGS = (GMG,SMG)
  IV = 0
  NV = 0
  PV = 0
  MAGIC = 0xce9828
    MG_VIRTUAL = &PL_vtbl_defelem
    MG_TYPE = PERL_MAGIC_defelem(y)
    MG_FLAGS = 0x02
      REFCOUNTED
    MG_OBJ = 0xcb2820
    SV = PV(0xcb2ed8) at 0xcb2820
      REFCNT = 1
      FLAGS = (POK,pPOK)
      PV = 0xce97f8 "akey"\0
      CUR = 4
      LEN = 10
  TYPE = y
  TARGOFF = 0
  TARGLEN = 1
  TARG = 0xce1a80
  FLAGS = 0
  SV = PVHV(0xcb8218) at 0xce1a80
    REFCNT = 2
    FLAGS = (SHAREKEYS)
    ARRAY = 0x0
    KEYS = 0
    FILL = 0
    MAX = 7
[download]

If this PVLV values is assigned to then it autovivifies the hash. If it is just read, it doesn't. It behaves kinda like a tied variable. Personally I don't like like this behaviour much, but it was added in 5.004, before my time as a p5 porter.

Dave.

Comment on Re^3: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) Select or Download Code

Replies are listed 'Best First'.
Re^4: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by LanX (Saint) on Dec 20, 2019 at 22:57 UTC
> Personally I don't like like this behaviour much, but it was added in 5.004, before my time as a p5 porter Which of both? I personally find the behaviour of the sub arg aliasing far less surprising. The other behaviour rather looks like sacrificing logic for performance or easier code logic. I suppose changing that might be too expensive now, but most code doesn't try to assign to $_ in a loop. If we are going to keep this behaviour, we'll need to document it properly. Something like loop aliasing always triggers autovivification Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^5: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by dave_the_m (Monsignor) on Dec 21, 2019 at 00:01 UTC
To clarify: I am happy with the fact that 'for', 'grep' etc evaluate their args in lvalue context and thus autovivify, and I don't wish it to change. I find that this behaviour makes the rules for autovivification logically simple(r) and consistent. I am unhappy with the deferring mechanism in hash lookups when used as an arg to a function call. It's a tricksy special-case behaviour and is hard to explain (above, I had to start talking about PVLVs and showing the output of Devel::Peek). It adds performance + memory overhead for such function calls, and is too clever for its own good. But I'm not proposing that it be be changed, since it was intentional behaviour added over 20 years ago. Dave.	[reply]
Re^6: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by LanX (Saint) on Dec 21, 2019 at 18:50 UTC
> I find that this behaviour makes the rules for autovivification logically simple(r) and consistent. Maybe... But if it was that easy why can't we find it documented in the perldocs. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l]
Re^4: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by Anonymous Monk on Dec 21, 2019 at 16:42 UTC
Here is the link do bug in 2016: https://github.com/Perl/perl5/issues/15583	[reply]
Re^5: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by Anonymous Monk on Dec 21, 2019 at 20:23 UTC
Re^3: unexpected modify hash in a distance with grep { $_ }	[reply]


Perl: the Markov chain saw
	PerlMonks