in reply to Hash keys not DWIMming

Perl is treating '512_x64' as an expression, where 'x' is the x operator. See the output from the following:

perl -MO=Deparse -e "$h{512_x64} = 10; print $h{512_x64}, qq/\n/;"

[download]

Though the syntax checks out 'ok', deparse makes it clear that Perl is seeing "512_x64" as the expression, 512 x 64.

As a refresher, 512 x 64 is the same as 512512512512512512512512...... where the sequence '512' is repeated 64 times. This is an unusual case where 512_ is treated as a number. Consequently the '_' is silently dropped, and then the 

x</x> operator stringifies it, so that the number 512 is stringified a
+nd repeated 64 times.</p>
<p>In your definition (ie, <c>%h = ( 512_x64 => 'value' );

[download]
, the => operator has the effect of wrapping "512_x64" in single quotes, so on that line you are properly populating the hash. But later on when you recall the hash value, the interpretation of $h{ ...... } is not protected by single quotes, explicitly or implicitly.


Dave

Replies are listed 'Best First'.
Re^2: Hash keys not DWIMming
by JavaFan (Canon) on Oct 07, 2010 at 07:59 UTC
    the => operator has the effect of wrapping "512_x64" in single quotes,
    No it doesn't. The fat comma doesn't follow different rules of autoquoting than hash keys do. 512_x64 isn't a valid identifier name, so it's not autoquoted. Not as a hash key, and not with a fat comma.

    Note also that autoquoting doesn't mean putting something in single quotes. Or double quotes. It just means the bare word is to be taken as a string, instead of something else.

[reply]

      I'm not arguing against your statement: "The fat comma doesn't follow different rules of autoquoting than hash keys do.".

      However, the target of autoquoting may be handled differently prior to autoquoting.

      Here's an example with constants:

      $ perl -wE 'use constant XXX => q{a}; my %x = (XXX() => 123); say $x{X
+XX()};'
123

$ perl -wE 'use constant XXX => q{a}; my %x = (XXX() => 123); say $x{+
+XXX};'
123

$ perl -wE 'use constant XXX => q{a}; my %x = (+XXX => 123); say $x{XX
+X()};'
Use of uninitialized value in say at -e line 1.

$ perl -wE 'use constant XXX => q{a}; my %x = (+XXX => 123); say $x{+X
+XX};'
Use of uninitialized value in say at -e line 1.

      [download]

      Note how both XXX() and +XXX can be used as the hash key but only XXX() works on the LHS of the fat comma.

      This example is run under 5.12.0 but I recall the same behaviour under 5.8 (definitely) and 5.6 (probably).

      I have a vague recollection that there's another instance of this type of behaviour but I can't think what it is right now.

      -- Ken

[reply]
[d/l]
[select]
        Note how both XXX() and +XXX can be used as the hash key but only XXX() works on the LHS of the fat comma
        Note that neither XXX() nor +XXX is quoted as a hash key - what is between the parens isn't a bare word. In all cases, the key is "a".

        There's nothing to autoquote in XXX() => 123 as there's no bare word directly left of the arrow. However, in +XXX => 123 there is a bare word left of the arrow: hence it's tokenized as +"XXX", 123.

[reply]
[d/l]
[select]
Re^2: Hash keys not DWIMming
by JavaFan (Canon) on Oct 07, 2010 at 08:37 UTC
    Consequently the '_' is silently dropped
    Really? Then what does the
    Misplaced _ in number at try.pl line 6.
    in the OP's output mean?
[reply]
[d/l]

In Section Seekers of Perl Wisdom