in reply to Re^10: If you believe in Lists in Scalar Context, Clap your Hands
in thread If you believe in Lists in Scalar Context, Clap your Hands

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.

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.)

Replies are listed 'Best First'.
Re^12: If you believe in Lists in Scalar Context, Clap your Hands
by JavaFan (Canon) on Oct 25, 2008 at 22:38 UTC
    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.

[reply]
      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.

[reply]
        One cannot pass a hash or array into a function intact.

        If that were true, push wouldn't work, and you couldn't override CORE::push. You're confusing pass by value/reference with first-classness.

[reply]
[d/l]
Re^12: If you believe in Lists in Scalar Context, Clap your Hands
by mr_mischief (Monsignor) on Oct 24, 2008 at 23:20 UTC
    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.

[reply]
[d/l]
[select]

      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?

[reply]
        What bearing should the implementation have upon the concept so long as the concept is not describing a different end result? Isn't the whole point of different levels of abstraction to enable, in as many instances as workable anyway, people to disregard how things work at the lower level? The microcode in the processor knows nothing of sv_this and av_that, after all.

        Let's go with the idea that it's the list assignment operator that is the only thing returning anything there. It returns to the scalar() built-in the count of elements in the list. What returns results to the list on the left, which receives as many results as there are elements present to take them? Isn't that also the list assignment operator? If it's returning something to scalar() and it's returning something to ( $x, $y ) as well, then you have a single operator returning two results in two different contexts within the same expression.

[reply]
[d/l]
[select]
      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
[reply]
[d/l]
        You are confused what I'm talking about. I'm not talking about how it happens in the interpreter. I'm talking about what appears to happen, so that people understand what the folks who talk about lists in scalar context are seeing from their POV. Look at the notation and pretend you know nothing about how perl works, and are only beginning with Perl.
[reply]

In Section Meditations