Of the two sentences you quoted, you only attempt to respond to one as far as I can tell.

The inclusion of the second sentence was accidental. I hadn't even read it. If JavaFan said that lists don't even exist, that I don't agree with him. I suspect that's not what he meant, though. I can't address this question for him.

Saying [...] does nothing to show that there's no context applied to the list.

I agree. Nothing will show that because everything is evaluated in some context.

Saying the values propagate from right to left through the contexts is equivalent to saying that the contexts propagate from left to right through the values.

Operands are evaluated in a context chosen by their operator. Precedence and associativity determine what is an operand to what operator, but doesn't otherwise affect context.

To clarify, by "an operator propagating a context onto an operand", I mean "an operator choosing to impose the same context upon an operand as the context imposed upon the operator itself".

What does "So while the list assignment is in scalar context, the assignee and assigned lists aren't." if the "list" doesn't exist?

Where did you get that from? I didn't say some list didn't exist. Quite the opposite, I showed two list operators in list context, so two lists were created.

What the heck is "list op'tor"? Does that stand for "list operator"?

Yup. I wanted to avoid reaching the default wrap length for code blocks.

() -- is a list?

Yes, an empty list literal.

scalar -- enforces scalar context?

Yes, onto its operand, the list assignement.

Show me the list assignment that is in scalar context here:

                       |
                       v
perl -E 'say scalar(() = ($a, $b, $c))'
         V   L      L  S  L \ L/  L
                             \/
                             L
[download]

Is there a list there?

Multiple.

• () (or rather the nothing inside the parens) is a list operator.
• ,, is a list operator (or two depending if you think of it as a binary operator).

• () returns a list of zero scalars.
• ($a, $b, $c) returns a list of three scalars.
• scalar(...) returns a list of one scalar.

Is there a set of scalar values context assignment operator present other than the one between the empty set of scalar values and the set of three scalar values?

What's a "scalar values context assignment operator"?

In what context is the empty set of scalar values?

You mean the ()? List context. The () is the LHS of a list assignment operator, and a list assignment operator imposes a list context on its LHS operand. (On its RHS operand too.)

If JavaFan said that lists don't even exist, that I don't agree with him. I suspect that's not what he meant, though.

What I said is that Perl doesn't know about lists. A list is not a Perl datastructure. Lists don't have names. Once the program is compiled, "lists" are just a bunch of scalars on the stack. In the same way that Perl doesn't really know about string literals. Once the program is compiled, a string literal is a value. Note also that I made the remark in response to a request for clearification about the difference arrays and lists. Arrays are first class objects. They (can) have names. They have their own datastructure. They can be referenced. Lists have none of that; they aren't even second class objects.

That of course doesn't mean that humans can't talk about lists. Just as humans can talk about object attributes - Perl wouldn't know what an object attribute is.

What constitutes a "first-class object" tends to vary by language. Strictly speaking in generic inter-language terminology, arrays and hashes in Perl are not first-class objects by many definitions. One cannot pass a hash or array into a function intact. One cannot return a hash or an array from a function, or assign one hash or array directly to another. Without library support (DBM::Deep or such) the values are what gets copied (with a hash key being a special type of "value" that is the key to another value).

The only first-class objects in a very strict sense of which I can think right now in Perl are scalars, references, typeglobs, and perhaps (classic, blessed reference to something) object instances. I hesitate to include object instances since they are "just blessed references", but when returned or assigned they do carry their class information and instance information with them at the language level.

The result of the whole expression is what I'd say is in scalar context, actually. Assess the context here:

perl -e 'print scalar( ($x, $y ) = ( 42, 101, 202 ) ); print "\n$x\n$y
+\n";'
[download]

The assignment operator itself happens to be both in scalar and in list context. It produces both a list for the list, and a scalar for the function scalar(). Which oddly leads to the possibility of saying the assignment operator in this:

perl -E 'say scalar(() = ($a, $b, $c))'
[download]

... is both in scalar and void contexts.

I'm not sure how this is any more clear than saying there are exceptions to a general rule about lists returning something of their own accord.

The assignment operator itself happens to be both in scalar and in list context. It produces both a list for the list, and a scalar for the function scalar().

You'll have to explain that. If it returns two values, what are they? How does it collapse into one value? How can you select which value you want? You're clearly speaking conceptually because that's not how perl is coded at all. So what advantages does your concept have?

The assignment operator itself happens to be both in scalar and in list context. It produces both a list for the list, and a scalar for the function scalar().

No. The assignment operator does the assignment, but it doesn't produce a list. The assignment is the side-effect; the result is a scalar due to the scalar context. Similar to how the ++ in perl -we'print $i++' produces 0 while incrementing $x.
--
Online Fortune Cookie Search
Office Space merchandise