I'm sure I read somewhere that this form can be best understood in terms of the implied or transparent comma -- from memory, that would be a Unicode "ZERO WIDTH NO-BREAK COMMA". (Known to some as the fairy or pixie comma, spreading a little List Context magic while remaining tantalizingly just out of sight. I believe that in Ireland this is also known as one of the extensive family of O'Mission leprechauns.)

To correct myself, there are very special situations where parens affect the result. eof vs eof() and (...)x... vs ...x..., for example. And of course ($x)=... vs $x=....

But while parens sometimes do more than control precedence, I can't think of anywhere where non-empty parens create a list context.

The parens in ($a)=@_ don't affect context. They cause a list assignment operator (aassign) to be used instead of a scalar assignment operator (sassign).

That said, it's very convenient to think that some parens create a list, even when it isn't technically true. But the code being discussed definitely does not contain parens which could be thought of as "list forming".

I've just been tripped up by:

  my @foo = (2, 3,  4  x 17, 3, 2, 0, 0)

being quite different from:

  my @foo = (2, 3, (4) x 17, 3, 2, 0, 0)

which looks as if the '()' confer some quality of list-ness. The documentation says:

.... In scalar context or if the left operand is not enclosed in parentheses, it returns a string consisting of the left operand repeated the number of times specified by the right operand. In list context, if the left operand is enclosed in parentheses or is a list formed by qw/STRING/, it repeats the list.

so the brackets are part of the syntax... I confess that I was (for reasons unknown) expecting 'x' to do listy things in List Context and scalary things otherwise. (Many things take lists of arguments, so I guess it would be inconvenient for (e.g.) '-' x 24 to yield a list in List Context.)

Similarly, of course,  foreach VAR(LIST) BLOCK reenforces the feeling that '()' have something to do with the making of lists.

I confess that I was (for reasons unknown) expecting 'x' to do listy things in List Context and scalary things otherwise

I recall the developers of Perl a bit ashamed of that one. I don't know if it was done that way for backwards compatibility or if it was simply a case of the consequences not being anticipated. It really does break the mold.

Similarly, of course, foreach VAR (LIST) BLOCK reenforces the feeling that '()' have something to do with the making of lists.

Really?

for (foo()) { bar() }    # List
while (foo()) { bar() }  # Scalar
if (foo()) { bar() }     # Scalar
print(foo())             # List
length(foo())            # Scalar
[download]

I even use for as a topicalizer regularly.

for ($var) {             # Scalar
   s/^/[/;
   s/$/]/;
}
[download]

The purpose of parens in flow control statements in Perl5 is purely decorative. However, their roots are in C, where their purpose is for precedence.

> The parens in ($a)=@_ don't affect context. They cause a list assignment operator (aassign) to be used instead of a scalar assignment operator (sassign).

I can't follow your interpretation ... aassign implies listcontext!

  DB<54> $a= join ",",(1..5)


  DB<55> p $a
1,2,3,4,5

  DB<56> print scalar split /,/,$a
5

  DB<57> ($A)=split /,/,$a


  DB<58> print $A
1
[download]

split is executed in listcontext!

Cheers Rolf

Yes, operators determine the context in which their operands are evaluated, and the aassign operator unconditionally evaluates its operands in list context. It's not based on the presence or absence of parens.

You previously said that the operand ("($a)") determined the context. An expression never decides the context in which its evaluated. The context in which its evaluated is always imposed upon it by its caller.

Even at the abstract level, the reason for using "($a)=" instead of "$a=" isn't to evaluate $a in list context. After all, $a evaluates to the same thing in both list and scalar context. The goal is to use the list assignment operator.