Parentheses don't create lists

I guess they do. At least they force list context:

qwurx [shmem] ~ > perl -le '$_ = "foo bar baz"; $c = /\w+/g; print $c'
1
qwurx [shmem] ~ > perl -le '$_ = "foo bar baz"; $c = () = /\w+/g; prin
+t $c'
3
[download]

<update>

The first line only prints out wether the match succeeded. The second form forces the match to be done in list context. The resulting list is then evaluated in scalar context. Or is that also a kind of disambiguation (of the match operator)?

qwurx [shmem] ~ > perl -le '$_ = "foo bar baz"; $c = (/\w+/g); print $
+c'
1
[download]

Hmm.. here they obviously don't force list context?

</update>

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I guess they do.

I hate being cruel... but read the parser.

Or is that also a kind of disambiguation (of the match operator)?

In one sense, those parentheses only mark the empty list, but it's probably more accurate to say that those do create a list. That's only true for the empty list however, as parsers have a very difficult time identifying invisible, non-existent characters.

Hmm.. here they obviously don't force list context?

Correct. Why would you expect them to do so? They're immaterial to the expression, just as in my $x = ( 2 + 2 );.

If parentheses did create lists, what would you expect this code to do?

my $x = ( 1 + 2 ) * 3;

Perl doesn't have a strict leftmost-applicative evaluation order, so the parentheses are necessary to disambiguate precedence.

That's the exact reason why the parentheses are necessary to group lists, but do not create lists. In:

my @fib_values = 1, 1, 2, 3;

... the expression my @fib_values = 1 is a complete expression to the parser as it is. Now it may be completely unambiguous to you that the entire expression is a list assignment, but there are plenty of more complicated assignment forms that involve mixed expressions such that Perl will give you a warning that it may have guessed wrong in this case.

Note also that you don't need parentheses when passing an argument list to a function or especially a built-in operator... again, unless you need to disambiguate something.

I hate being cruel... but read the parser.

Mhm. That's been on my todo list for a long time now. The parser, the tokenizer and the lexer. Well.. lots of excuses..

In one sense, those parentheses only mark the empty list, but it's probably more accurate to say that those do create a list.

as is the case with

@list = (1) x 15;
[download]

If parentheses did create lists, what would you expect this code to do?

my $x = ( 1 + 2 ) * 3;

I would expect the parens to do grouping. I didn't assume that parens always create lists (which they don't), but that they do - sometimes:

$_ = "foo bar baz";
$middle = (split)[1];
[download]

Well, as everywhere with perl - contetxt matters...

--shmem

update: replaced nonsensical $_ = qw(foo bar baz) with $_ = "foo bar baz". Common typo ;)

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Indeed. But personally I consider it a matter of good style always to enclose the RHS of an array assignment in parentheses for the sake of consistency, since they are necessary in some situations. And you can't exactly say it's a bad habit to get into...

One exception I make, in my own programming style, is when the RHS is a single function call, e.g. @a = stat;