leszekdubiel has asked for the wisdom of the Perl Monks concerning the following question:

Hello Perl Monks!

In perl5 there is a strange behaviour that hash values are sometimes initialized to undef and sometimes not. See this example:

#!/usr/bin/perl -CSDA use utf8; use Modern::Perl; no warnings qw{uninitialized numeric}; use Data::Dumper; my %h = (a => 'alfa', b => 'beta'); print "\n\nfirst try:\n"; print "\t>>$h{a}<<\n"; print "\t>>$h{XXX}<<\n"; print "\t>>$h{b}<<\n"; print "after first:\n", Dumper(\%h); print "\n\nsecond try:\n"; print map { "\t>>$_<<\n" } $h{a}, "mytext" . $h{YYY} . "after", $h{b}; print "after second:\n", Dumper(\%h); print "\n\nthird try:\n"; print map { "\t>>$_<<\n" } $h{a}, $h{ZZZ}, $h{b}; print "after third:\n", Dumper(\%h); ===================== OUTPUT: first try: >>alfa<< >><< >>beta<< after first: $VAR1 = { 'a' => 'alfa', 'b' => 'beta' }; second try: >>alfa<< >>mytextafter<< >>beta<< after second: $VAR1 = { 'a' => 'alfa', 'b' => 'beta' }; third try: >>alfa<< >><< >>beta<< after third: $VAR1 = { 'b' => 'beta', 'ZZZ' => undef, <<<<<<------------ ?????? 'a' => 'alfa' };

Hash values are only used to form strings. Why sometimes they got initialized to "undef" and sometimes not? Does Raku (Perl6) has similiar behaviour?

This is what I asked in autovivification context: https://www.perlmonks.org/?node_id=11110437.

  • Comment on Sometimes undef is initialized and sometimes not when hash values are fed to grep
  • Download Code

Replies are listed 'Best First'.
Re: Sometimes undef is initialized and sometimes not when hash values are fed to grep
by haukex (Chancellor) on Feb 11, 2020 at 16:42 UTC

    I'm pretty sure the answer is the same as in your previous thread that you referenced: map is providing lvalue context to its args, while the other two examples of string concatenation do not, hence the hash value is autovivified. (Update: I added LanX's suggested workaround to the following example).

    $ perl -wMstrict -MData::Dump -e 'my %h; map{$_} $h{X},"$h{Y}"; dd\%h' Use of uninitialized value $h{"Y"} in string at -e line 1. { X => undef }

    See also your previous thread No autovivification, for loop aliasing, lvalue vs rvalue in for loops.

    I'm curious why you have so many issues with autovivification? Personally, I hardly ever do, because I use exists, or keys when looping over multiple hash keys. And if I have a situation where I want to control which keys can be accessed, I use locked hashes from Hash::Util.

      > I'm curious why you have so many issues with autovivification? I hardly ever do, because I use exists,

      Please note that he is also explicitly deactivating some warnings to avoid exists

      no warnings qw{uninitialized numeric};

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: Sometimes undef is initialized and sometimes not when hash values are fed to grep (already discussed)
by LanX (Archbishop) on Feb 11, 2020 at 16:36 UTC
    We had a similar discussion recently.°

    What's happening in "third try" is that you are passing an alias to map which is forcing an autovivification.

    The second try is only a copy.

    One workaround would be to surround every value with quotes "$h{bla}" , to enforce a copy.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

    °) I'll link to it ... here it is: unexpected modify hash in a distance with grep { $_ }

    Well, it's the last thread you started and the one you linked to (!?!)

      Here two or three workarounds (can't test the latter)

      use utf8; use strict; use warnings; use Data::Dumper; my %h = (a => 'alfa', b => 'beta'); print "\n\nWorkaround 1 \n"; print map { "\t>>$_<<\n" } "$h{a}", "$h{111}", "$h{b}"; print "after third:\n", Dumper(\%h); print "\n\nWorkaround 2 \n"; print map { "\t>>$h{$_}<<\n" } qw/a 222 b/; print "after third:\n", Dumper(\%h); # print "\n\nWorkaround 3 \n"; # no autovivification; # print map { "\t>>$_<<\n" } $h{a}, $h{333}, $h{b}; # print "after third:\n", Dumper(\%h);

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        can't test the latter

        Unfortunately, that one doesn't work:

        use warnings; use strict; use Data::Dumper; no autovivification; my %h = (a => 'alfa', b => 'beta'); print map { ">>$_<<\n" } $h{a}, $h{333}, $h{b}; print Dumper(\%h); __END__ Use of uninitialized value $_ in concatenation (.) or string at 111127 +86.pl line 8. >>alfa<< >><< >>beta<< $VAR1 = { '333' => undef, 'a' => 'alfa', 'b' => 'beta' };
Re: Sometimes undef is initialized and sometimes not when hash values are fed to grep
by leszekdubiel (Beadle) on Feb 11, 2020 at 21:03 UTC

    @LanX

    One workaround would be to surround every value with quotes "$h{bla}" , to enforce a copy.
    -- thank you. That's good hint. I have tried also $h{bla} // "".

    @haukex

    I'm pretty sure the answer is the same as in your previous thread that you referenced: map is providing lvalue context to its args, while the other two examples of string concatenation do not, hence the hash value is autovivified.
    Yess.. this is the same problem. Sorry for coming again with the same...

    $ perl -wMstrict -MData::Dump -e 'my %h; map{$_} $h{X},"$h{Y}"; dd +\%h' Use of uninitialized value $h{"Y"} in string at -e line 1. { X => undef }
    Hmmmm... only one warning... It doesn't warn about X. Educative example.

    I'm curious why you have so many issues with autovivification? Personally, I hardly ever do, because I use exists, or keys when looping over multiple hash keys.
    In my company (dubielvitrum.com, manufacturer of mirrors) there is manufacturing system written in perl. And all data is kept in structured files, with strict data types (numbers, identifiers, quoted texts). This data is checked carefully on input and output. When undef gets somehow into hash then error is thrown. So I have to search how undef got injected into data structures. Original piece of code that made that error was like this:

    $wi{OrderUniqueId} = join " ", grep { $_ ne "" } map { unquote +_text($_) } ($ty eq "need" ? "Zamów" : "Posia"), $$it{name}, $$it{ +para}{Termin}, $$it{para}{Ile}, seq_num(6);

    To build OrderUniqueId I take (1) word "Zamów" or "Posia" (2) name of item (3) parameter "Termin" (4) parameter "Ile" (6) some sequence number -- take all non empty of these, join them with spaces.

    $wi{OrderUniqueId} = join " ", grep { $_ ne "" } map { unquote_text($_ +) } ($ty eq "need" ? "Zamów" : "Posia"), $$it{name}, $$it{ +para}{Termin} // "", $$it{para}{Ile} // "", seq_num(6);

    Normally when working with perl I hardly ever got errors from autovivification when aliased with grep or  map.

      This data is checked carefully on input and output. When undef gets somehow into hash then error is thrown.

      Ok, I see. Although of course there are exceptions, I find it easiest to work with hashes in one of two ways: either a fixed set of possible keys, in which case one can avoid autovivification issues by not differentiating between exists and defined, so it doesn't matter whether a key is present or not, and undef simply indicates "no value". Or, the other situation is a set of keys that is unknown to the code beforehand, in which case one generally only iterates over the hash with keys etc., and one doesn't generally access specific hash keys by name.

      It sounds like you might be mixing these two - although there are sometimes valid cases where a hash has a known set of keys and one does want to differentiate between exists and defined, I've found this to be a little annoying to work with. For example, in my module IPC::Run3::Shell, there are options that can be exists but not defined, but then there is no easy way to override these options so they no longer exist in the hash.

      Anyway, In the code you showed, I might have gone with exists checks to prevent autoviv, even if that makes the code more verbose.