The outer pair of curlies with the sigil dereferences the anonymous hash created by the inner pair, acting on the list returned by the block in the innermost pair, which is the argument to map. keys wants a hash.

Also, Edit: Also, you likened "array" to:

$VAR1 = [
          'one',
          'fish',
          'two',
          'fish',
          'red',
          'fish',
          'blue',
          'fish'
        ];
[download]

But for your last question, if you want an array containing the flattened hash derived from your map and then want to dumper it to get the output you showed:

say Dumper( [ map { $_ => "fish" } qw(one two red blue) ] );
[download]

Aaaaah. I get it.

So this is how to get the array:

say Dumper(\@{ [map { $_ => 'fish' } qw(one two red blue)] } );
[download]

I had tried

say Dumper(\@[ {map { $_ => 'fish' } qw(one two red blue)} ] );
[download]

after having half convinced my self the inner braces were a code block, but of course that didn't work either ...

Thank you very much.

Thanks,
cbeckley

Although it is technically a block, it's really an operator. %{} and @{} are often referred to as the "circumfix operators". They are available wholly to dereference what is within the block to whatever sigil is placed before it.

\@{ [map { $_ => 'fish' } qw(one two red blue)] }
[download]

Well, that works but it's a bit wasteful: first you're creating a arrayref with [], then you're dereferencing it with @{}, and then taking a reference to that again with \. It's easier to just use one set of []'s like 1nickt showed (although you may not have seen that yet since it was part of a large ninja edit).

Nope, one level too many of referencing / deferencing. See my example above.

With this kind of thing it's best to strip it down to the innermost element and print its output with a data dumper. Then when you understand what is going on, add a layer, repeat. Trying to get at it from the outer edge when you are confused is a bit like flailing. A methodical approach is most effective.



The way forward always starts with a minimal test.

Is there a reference dereference happening?

Yes - the curlies directly around the map create a hash reference from the list that map returns (see number 3 in Making References), and then the outer %{ } dereferences that hash reference (see number 2 in Using References).

So the inner pair is a code block.

Nope, it's a hashref constructor, but since it can also look like a block, Perl sometimes has to "guess" which one it is, and AFAIK that's where the warning is coming from.

If I need to return an array, as opposed to a list or a hash, what would that syntax be?

The same kind of reference-dereference operation, just in this case create an arrayref with [...] and dereference it with @{...}:

print Dumper @{ [ map {"<$_>"} qw/a b c/ ] };
__END__
$VAR1 = '<a>';
$VAR2 = '<b>';
$VAR3 = '<c>';
[download]

Although I think this is needed less often than the %{{...}} trick when it comes to passing stuff to functions, since most functions impose list context on their arguments anyway. However, it is sometimes used as a trick to interpolate things into strings that don't normally interpolate, so for example:

sub foo { return "World!" }
print "Hello, ", foo(), "\n";   # prints "Hello, World!"
print "Hello, foo()!\n";        # prints "Hello, foo()!"
print "Hello, @{[ foo() ]}\n";  # prints "Hello, World!"
[download]

While in this example the first print looks cleaner than the last, the trick can sometimes be useful when interpolating things into long heredocs, for example.

Thank you again. A lot of information as always.

It makes sense that there wouldn't be too many @{[...]]} running around in the wild.

Thanks in particular for this:

print "Hello, @{[ foo() ]}\n";  # prints "Hello, World!"
[download]

Thanks,
cbeckley