Re: unexpected modify hash in a distance with grep { $

the $_ inside the grep is an alias of the hash-values, i.e. any assignment would be mirrored.

For reasons that I don't understand yet (under-coffeination perhaps) this triggers an autovivification. °

compare Re^2: unexpected modify hash in a distance with grep { $_ }

This can easily circumvented with a more common approach to only pass the keys.

#!/usr/bin/perl 

use strict;
use warnings;
use Data::Dumper;

my $h = {
          'a' => 1,
          'b' => 2,
          'c' => 3,
        };

warn Dumper [ $$h{a}, $$h{x}, $$h{b}, $$h{c} ];
warn Dumper [ keys %$h ];

warn Dumper [ grep {$$h{$_}} qw/a b c x/ ];      # <-- no side effect
warn Dumper [ keys %$h ];
[download]

C:/Perl_524/bin\perl.exe  d:/tmp/pm/grep_autovivify.pl 
$VAR1 = [
          1,
          undef,
          2,
          3
        ];
$VAR1 = [
          'a',
          'c',
          'b'
        ];
$VAR1 = [
          'a',
          'b',
          'c'
        ];
$VAR1 = [
          'a',
          'c',
          'b'
        ];
[download]

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

°) my guess is it's an implementation detail/bug

Comment on Re: unexpected modify hash in a distance with grep { $_ } Select or Download Code

Replies are listed 'Best First'.
Re^2: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by LanX (Saint) on Dec 20, 2019 at 18:39 UTC
It seems to be a general issue that accessing an alias is sometimes triggering autovivification. Didn't know that. Smells like bug. `#!/usr/bin/perl use strict; use warnings; use Data::Dumper; my $h = { 'a' => 1, 'b' => 2, 'c' => 3, }; warn "x: ",$_ for $$h{x}; # autovivifiaction via alias warn Dumper [ keys %$h ]; tst($$h{y}); # no autovivification warn Dumper [ keys %$h ]; sub tst { warn "y: ",$_[0] ; }` [download] `C:/Perl_524/bin\perl.exe d:/tmp/pm/grep_autovivify.pl Use of uninitialized value $_ in warn at d:/tmp/pm/grep_autovivify.pl +line 13. x: at d:/tmp/pm/grep_autovivify.pl line 13. $VAR1 = [ 'c', 'x', 'b', 'a' ]; Use of uninitialized value $_[0] in warn at d:/tmp/pm/grep_autovivify. +pl line 24. y: at d:/tmp/pm/grep_autovivify.pl line 24. $VAR1 = [ 'c', 'x', 'b', 'a' ];` [download] Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l] [select]
Re^3: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) by dave_the_m (Monsignor) on Dec 20, 2019 at 22:38 UTC
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.	[reply] [d/l] [select]
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
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
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^2: unexpected modify hash in a distance with grep { $_ } by haukex (Archbishop) on Dec 20, 2019 at 18:34 UTC
the $_ inside the grep is an alias of the hash-values, i.e. any assignment would be mirrored. For reasons that I don't understand yet (under-coffeination perhaps) this triggers an autovivification. My educated guess is that it's because autovivification generally happens in an lvalue context.	[reply]
Re^3: unexpected modify hash in a distance with grep { $_ } by LanX (Saint) on Dec 20, 2019 at 18:41 UTC
> My educated guess is that it's because autovivification generally happens in an lvalue context. Good guess, but I can't see lvalue in these inconsistent results when aliasing: Re^2: unexpected modify hash in a distance with grep { $_ } (inconsistent behaviour of aliasing) edit My educated guess is rather that dave_the_m will digg into the sources now and point us to a (known?) glitch! ;-) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^3: unexpected modify hash in a distance with grep { $_ } by LanX (Saint) on Dec 20, 2019 at 22:47 UTC
Found another related discussion, curiously from the same OP. No autovivification, for loop aliasing, lvalue vs rvalue in for loops The related bug report argues, that aliases must trigger autovivification beforehand, in case an lvalue happens after. https://github.com/Perl/perl5/issues/15583 I find this explanation unsatisfactory because I showed here that the aliasing of sub arguments don't trigger autovivification. Hmm??? Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]

edit