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

Understanding the more common-place notion of right-associativity is not enough.
Indeed. You must also know the return value of the operator (= in this case). But that's the same as trying to understand the result of
2 ** 3 ** 4
you need to understand the return value of ** beside understanding right-associativity.
I do not know how this is actually implemented.
Associativity is a parser/compiler issue. By the time the code is running, associativity no longer plays a role. As for the implementation of assignment, they are actually two different operators, scalar assignment (pp_sassign in pp_hot.c) and list assignment (pp_aassign in pp_hot.c).

And if you look in pp_hot.c, you see there's check on context to determine what is returned: 

    if (gimme == G_VOID)
        SP = firstrelem - 1;
    else if (gimme == G_SCALAR) {
        dTARGET;
        SP = firstrelem;
        SETi(lastrelem - firstrelem + 1 - duplicates);
    }
    else {
        if (ary)
            SP = lastrelem;
        else if (hash) {
            if (duplicates) {
                /* Removes from the stack the entries which ended up a
+s
                 * duplicated keys in the hash (fix for [perl #24380])
+ */
                Move(firsthashrelem + duplicates,
                        firsthashrelem, duplicates, SV**);
                lastrelem -= duplicates;
            }
            SP = lastrelem;
        }
        else
            SP = firstrelem + (lastlelem - firstlelem);
        lelem = firstlelem + (relem - firstrelem);
        while (relem <= SP)
            *relem++ = (lelem <= lastlelem) ? *lelem++ : &PL_sv_undef;
    }
            
    RETURN;

[download]
Now, I don't expect you to understand everything (neither do I), but I do hope you see that in VOID context, nothing is returned, in SCALAR context, a single value is returned, and in LIST context, more things are returned.

One more piece of evidence that it isn't the scalar assignment that is reaching all the way behind, here we have a list assignment in scalar context where the scalar context isn't given by another assignment: 

$ perl -E 'say scalar(() = ($a, $b, $c))'
3
$

[download]

Replies are listed 'Best First'.
Re^8: If you believe in Lists in Scalar Context, Clap your Hands
by mr_mischief (Monsignor) on Oct 24, 2008 at 17:51 UTC
    One more piece of evidence that it isn't the scalar assignment that is reaching all the way behind, here we have a list assignment in scalar context where the scalar context isn't given by another assignment:

    If you can't have a list in a scalar context, how can you have the assignment of a list in scalar context? You have even said in this thread that lists don't even exist.

    To pick your own nit, perhaps you meant "the result of the list assignment operator upon assigning a series of scalars to an empty series of scalars".

    It's very difficult for there to be a list assignment in scalar context there if lists don't exist. What does a "list assignment" assign? It's also very difficult to support the idea that lists don't exist when you show the code that returns multiple scalars ("atoms" and references to other complex structures) in order (a "list") in LIST context with variables named 'lelem' and similar. The "elem" part of those clearly stands for "element". Elements of what?

    You can argue that there is another, clearer concept to use to understand this topic. It's very difficult to support the idea that the concept used in the documentation, the source code, the tutorials, and the in concepts and culture of other programming languages from which Perl borrows ideas does not exist in Perl, though. Call it flawed if you like, but saying it doesn't exist is inaccurate.

[reply]

      If you can't have a list in a scalar context, how can you have the assignment of a list in scalar context? You have even said in this thread that lists don't even exist.

      The list assignment imposes a list context on its operands. So while the list assignment is in scalar context, the assignee and assigned lists aren't. 

         A     B      C     D        <-- labels
$x = ( $i, $j ) = ( $p, $q ); 
S  ?   L L L    S   L L L      <-- context
|  |   | | |    |   | |  \__ Propogated by right-most list op'tor (D).
|  |   | | |    |   |  \____ Imposed by the list assignment (C).
|  |   | | |    |    \______ Propogated by right-most list op'tor (D).
|  |   | | |     \__________ Imposed by the scalar assignment (A).
|  |   | |  \_______________ Propogated by left-most list op'tor (B).
|  |   | \__________________ Imposed by the list assignment (C).
|  |    \___________________ Propogated by left-most list op'tor (B).
|   \_______________________ Determined by outside code.
 \__________________________ Imposed by scalar assignment (A).

      [download]
[reply]
[d/l]

        Now try and replace all the information conveyed by the use of the word 'list' in the following sentence from perlsub, with the one or two dozen diagrams like the above, it would take to replace that one word.

        If you return one or more aggregates (arrays and hashes), these will be flattened together into one large indistinguishable list.

        The only purpose served by the "there's no such thing as a list in a scalar context" meme, is the promotion of one person's intimate knowledge of perl's internals over another's lack thereof; or lack of interest in same.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Thanks for the diagram, but it does not answer my point, let alone refute it. Of the two sentences you quoted, you only attempt to respond to one as far as I can tell.

        Saying "the context of the assignment operator is scalar, which changes what particular representation of the list is propagated" does nothing to show that there's no context applied to the list. 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.

        Now, about that second sentence you quoted... If there is no list, how can there be a list assignment? In what language are you writing that looks so much like English but in which "list assignment" does not mean "assignment of a list"?

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

        What the heck is "list op'tor"? Does that stand for "list operator"? Upon what does a "list operator" operate?

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

        $ perl -E 'say scalar(() = ($a, $b, $c))'
               |      |
                \      \_____ is a list?
                 \
                  \__________ enforces scalar context?

                     ?_______ second list assignment?

        [download]

        Is there a list there? 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? In what context is the empty set of scalar values?

        I don't believe you've shown there's no concept of a list being coerced into a scalar context. I especially don't believe you've shown there's no concept of a list in Perl.

[reply]
[d/l]
      If you can't have a list in a scalar context, how can you have the assignment of a list in scalar context?
      Because any operator can be scalar context; it's the context that determines its context, not their operands. Here are a few examples of operators in scalar context: 
      scalar ($a + $b);     # Addition
scalar (($a) x $b);   # Repetition
scalar ($a =~ $b);    # Matching
scalar ($a .. $b);    # Range/FlipFlop
scalar ($a = $b);     # Scalar assignment
scalar (($a) = ($b)); # List assignment

      [download]
      Here are some examples of operators in list context: 
      say ($a + $b);        # Addition
say (($a) x $b);      # Repetition
say ($a =~ $b);       # Matching
say ($a .. $b);       # Range/Flipflop
say ($a = $b);        # Scalar assignment
say (($a) = ($b));    # List assignment

      [download]
      One should realise that 'scalar assignment' and 'list assignment' are two different operators (sassign and aassign in pp_hot.c). It's the LHS of the '=' that determines which operator it is (this is unlike the '..' operator where it's the context that determines whether it's the range or the flipflop operator). The side-effects (that is, the actual assignment) of both sassign and aassign are independent of the context. However, the return value of the aassign operator is context dependent. In scalar context, it returns the number of elements appearing on its RHS.
[reply]
[d/l]
[select]

        it's the context that determines its context

        Deep recursion on "context" at PerlMonks post 719579
Terminating on signal SIGINT(2)

        [download]
        :)
[reply]
[d/l]
        Because any operator can be scalar context, including the list operator.
[reply]
[reply]
        No. Just, no.

        People are saying there are only three little things to remember so their model is much simpler.

        The ideas that "list" is a "value", "assignment" is an "operation", and that a "list of scalars" in the syntax does not become a "list value" in the semantics are at least three more concepts to that abstraction.

        It's not a non-question, because I can answer how it happens: a list of scalars doesn't propagate its own value, and in an assignment is processed by the assignment operator which in a scalar context returns the last value in the list. This last value is typically the last value returned by the comma operator.

        Without the additional concepts of "list of scalars" vs. just "list", "list value" vs. just "list", the idea that the syntactic "list of scalars" is not what propagates the value, that the assignment operator does, and just what the comma operator is doing (or that it is an operator at all and not just part of a "list syntax"), the simple "three" rule explanation doesn't explain anything to the uninitiated.

[reply]

In Section Meditations