This is a bug:
map { "$_" => "$_" } @array
Not only is that a bug, I know how to fix it and I won't have a problem with that again. Unfortunately, when I encountered this, it was strange and mysterious behavior to me. I searched for an explanation. I searched Perlmonks. I Googled. I boggled my fellow programmers. I boggled myself.
The answer, of course, was in perldoc -f map. I should have known better.
Re:Why bug?
vsergu on 2003-09-11T13:38:30
Did you try it? It gives a syntax error, presumably because perl thinks the braces are indicating an anonymous hashref (which would need a following comma) rather than a block. Getting rid of the quotes around the first $_ is one way to fix it. Maybe it's not a bug (it is more or less documented in perlfunc), but the rules for the syntax certainly aren't obvious.Re:Why bug?
Ovid on 2003-09-11T14:34:15
There are plenty of ways to fix it. Probably the clearest is to wrap the
in parentheses."$_" => "$_"map { ("$_" => "$_") } @array;In this case, it doesn't look terribly useful because it's a simplified test case. I discovered this when I and another programmer were being forced to walk symbol tables and pull out the CODE slot of blobs and examine them. I think posting the code we used to do that would have confused things even more
:) As it stands, better examples are in perldoc and they show why the difficult syntax could be useful. For example, you have an array of names and you want to test for the existence of them, the case doesn't matter:
my %names = map { "\L$_" => 1 } @namesOn the surface it looks valid. You can have lots of fun confusing your coworkers with it, though!
Re:Why bug?
ethan on 2003-09-11T16:49:55
Oh! So I guess this one would have got me as well. It isn't always quite transparent to me when perl considers a pair of curlies constructors for an array-ref or rather for a code-block.