( I didn't mean to post Re^13: chopping a string into slices - is there a more elegant way to do it?. I meant to start fresh and post the following instead. )

You're basically saying that [...]

My point is simply parens don't create lists except when empty. That's it.

LanX is contradicting that, saying that parens can sometimes create a list. My rebuttal is:

1. There are important differences between scalar and list assignment operators,
2. Parens on the LHS of an assignment can force the selection of one operator over the other, and
3. It's not because parens magically create lists some of the time.

perl as I understand it:

1. Parens on the LHS of an assignment operator force the selection of the list assignment operator.
2. The list assignment operator creates a list of both its operands.

The abstraction pushed by LanX, if I understand him correctly:

1. Parens on the LHS of an assignment operator force the creation of a list.
2. A list on the LHS of an assignment operator forces the RHS operand of the assignment operator to be treated as a list.

He hasn't had a chance to explain how that accounts for the difference in the output of scalar(($a)=5) and scalar($a=5)

Context is a run-time issue, so that is a completely separate thing and can't influence which assignment we pick.

Sometimes context is known at run-time, but not always.

>perl -MO=Concise -e"f()" 2>&1 | find "entersub"
5     <1> entersub[t2] vKS/TARG,1 ->6
                       ^
                       |
                       void

>perl -MO=Concise -e"0+f()" 2>&1 | find "entersub"
6        <1> entersub[t2] sKS/TARG,1 ->7
                          ^
                          |
                          scalar

>perl -MO=Concise -e"print f()" 2>&1 | find "entersub"
6        <1> entersub[t2] lKS/TARG,1 ->7
                          ^
                          |
                          list

>perl -MO=Concise -e"return f()" 2>&1 | find "entersub"
6        <1> entersub[t2] KS/TARG,1 ->7
                          ^
                          |
                          unknown at compile-time
[download]

It's used by the optimizer.

>perl -MO=Concise -e"'foo'"
3  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
-     <0> ex-const v ->3                  <-- The constant in void
-e syntax OK                                  context was removed
                                              from the execution path.
[download]

> He hasn't had a chance to explain how that accounts for the difference in the output of scalar(($a)=5) and scalar($a=5)

OK, my interpretation: the outer parens enclose to the params passed to scalar(). Both lines evaluate the result of the assignment in scalar context.

  DB<36> print scalar (($a)=5)
1                                  # Number of elements in list
  DB<37> print scalar ($a=5)
5                                  # value of $a
[download]

as you can see there is no measurable difference between (),(2),(1,2)

  DB<41> print scalar (@a=(5,6))
2

  DB<42> print scalar (@a=(6))
1

  DB<43> print scalar (@a=())
0
[download]

whats notable is that ($a) is evaluated like a literal array!

  DB<49> print scalar ( ($a)=(5,6,7) )
3

  DB<50> print scalar ( ($a,$b)=(5,6,7) )
3

  DB<51> print scalar ( ()=(5,6,7) )
3
[download]

AFAIR what one expect as "the scalar of a list" should be the last element and only the scalar of an array is the number of elements.

So the results prooves once again how problematic it is in perl5 to see the difference between arrays and lists!

Maybe as a rule of thumb: Lists are immutable, so what looks like "a list at the LHS" has to be an array !

Cheers Rolf

List assignment is chosen because "()" on the LHS of "=" is special-cased to become a list assignment in that situation. The list is formed as a result of the list assignment being chosen, and gets created even if no parens are present.

Exactly. But, the choice of list assignment is happening at compile time and therefore is independent of context.

You have been saying this without my understanding because I was missing when the list assignment was chosen instead of scalar assignment.

Like most important points, yours is immediately obvious once I understood my invalid assumption.

As I said, this has been a most enlightening discussion. Thank you.

G. Wade