bareword hash keys

[John M. Dlugosz]

What are the rules concerning implicit treatment of barewords as strings when Perl knows it's a hash key? If I didn't know better, I would have thought that the same rules as an identifier apply. But I've seen a leading - character used, such as in named parameters to functions. For example:

require v5.8;
use strict;
use warnings;

my %XX;

$XX{a}= 1;
$XX{-b}= 2;
$XX{+c}= 3;  #bareword 'c' not allowed.  Interpreted as + applied to f
+unction call c().

print (join (", ", keys (%XX)), "\n");

The -b is taken implicitly as '-b', but the same doesn't happen with +c.

Is anything allowed before, among, after the letters besides this? I can't find anything in the perldocs.

—John

[merlyn]

Yes, it's the same rule as a simple identifier, with an optional minus. The plus specifically indicates that it should not be a bareword.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

[diotalevi]

My $h{+__PACKAGE__} is still thanking you for that.

[dmmiller2k]

Some modules use hash keys beginning with a '-' for certain attributes of objects defined therein (witness, CGI.pm).

The use of a leading '+' before an expression within curly braces may be used to force Perl to treat the expression as a hash key or value, rather than parsing the whole thing as a block.

Not certain if this answers your question precisely, and I am particularly unsure exactly in what ways Perl 5.8 differs from 5.6, but this has been my experience with 5.6 and below.

[theorbtwo]

You confusion is between '-' being part of the bareword, and - as the unary negation operator. perl -MO=Deparse,-p -e "$foo{-bar}" outputs $foo{-'bar'};. The scalar negation operator is defined rather oddly in perl -- when you try to negate a string, it doesn't nummify and then negate (which would give 0), but rather prepends a dash.

There is still some bareword magic going on, to turn the b (in your example) into 'b' rather then a call to the (non-existant) b() function.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[John M. Dlugosz]

Interesting. The "bareword is OK" context must propigate inward, too. I suppose that's a special case of the - and not something that applies to any operator that takes/returns a string. Quick check indicates that's the case.

[waswas-fng]

Why not just get into the habit of using $XX{"+c"} = 3; or $XX{'+c'} = 3;?

Edited: I know this does not answer your question, but I am really wondering what advantage you get by using barewords that is worth putting special logic in your code to stop people from for instance using a +c as the key.

-Waswas

[John M. Dlugosz]

Because it was a royal pain before the bareword-as-key feature! I don't want to go back.

[jkenneth]

Just cause I dealt with it last week, using a . also causes problems as the . gets eaten and doesn't become part of the key.

Simple example:


$var{test.dot} = "a";
print keys %var;

prints testdot.

I know it's becuase of the dot operator but it still took my by surprise for a second.

JK

[Aristotle]

$ perl
use strict;
my %var;
$var{test.dot} = "a";
^D
Bareword "test" not allowed while "strict subs" in use at - line 3.
Bareword "dot" not allowed while "strict subs" in use at - line 3.
Execution of - aborted due to compilation errors.

That's why you should use strict.

Makeshifts last the longest.