Put the list into parens

  DB<105>  map { ( "x" => $_ ) } qw(1 2 3); 
 => ("x", 1, "x", 2, "x", 3)

  DB<106>  map { ( "x" => $y ) } qw(1 2 3); 
 => ("x", undef, "x", undef, "x", undef)

  DB<110> @opts = map { ( "$_=s" => \$opt{$_} ) } @vals;
 => ("title=s", \undef, "artist=s", \undef, "album=s", \undef)
[download]

Rolf was faster with his answer than me. Allow one annotation: perldoc -f map has a paragraph explaining this ambiguity.

McA

oops true! =)

 
               "{" starts both hash references and blocks, so "map { ..."
               could be either the start of map BLOCK LIST or map EXPR, LIST.
               Because perl doesn’t look ahead for the closing "}" it has to
               take a guess at which its dealing with based what it finds just
               after the "{". Usually it gets it right, but if it doesn’t it
               won’t realize something is wrong until it gets to the "}" and
               encounters the missing (or unexpected) comma. The syntax error
               will be reported close to the "}" but you’ll need to change
               something near the "{" such as using a unary "+" to give perl
               some help:

Since PBP "map EXPR, LIST" fell completely out of my scope, but it explains why a hash-ref could even be considered valid here.

Cheers Rolf

( addicted to the Perl Programming Language)

It is a well-known limitation of the perl parser.

It decides that this: map { ... => ... } ... is a map returning a hashref; and then the absence of a comma means if doesn't have enough arguments.

Fix it by giving it a hint that the curlies are a code block like this: map {; "x" => $y } qw(1 2 3);

Why does this work? (same result as your proposals)

my %opt;
my @vals = qw(title artist album);
my @opts = map { "$_"."=s" => \$opt{$_} } @vals;
print @opts;
[download]

UPDATE: Guess: Because there is some statement in there that needs to be executed rather than a static string only?

> Why does this work? (same result as your proposals)

There is no clear rule to distinguish between code-block and hash-ref!!!

The parser uses DWIM heuristics to guess if it looks more like a hash-ref or not. (Furthermore "w/o look-ahead")

So in complicated cases you need to give hints for what you mean.

This ambiguity should be one reason why Perl6 switched from {} to <> to indicate hashes.

> UPDATE: Guess: Because there is some statement in there that needs to be executed rather than a static string only?

well it's a perfect hash-ref!

  DB<112> $hr={ "$_"."=s" => \$opt{$_} }
 => { "=s" => \undef }
[download]

But I think the used heuristic must be quite simple, something like

  (bareword || variable) (comma || fatcomma) (expr)

So "$_"."=s" is already to complex to fit this rule of thumb.

Cheers Rolf

( addicted to the Perl Programming Language)

Guess: Because there is some statement in there that needs to be executed rather than a static string only?

Indeed.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

And just for completeness, to disambiguate the other way, use a leading +:

map +{ "x" => $y }, qw(1 2 3);
[download]

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

map +{...      map EXPR, LIST
map {;...      map BLOCK LIST
[download]