Re^11: chopping a string into slices - is there a more elegant way to do it?

My recollection was that assignment determined it's context by the left-hand side of the operation.

That's impossible for two reasons.

The assignment type is always known at compile-time, but the context is not necessarily.
The type of assignment determines the context of the operands, so the context of the operands cannot determine the type of assignment. Chicken and egg.

Your code shows that the type of assignment is determined by its LHS, but noone's disputing that.

This seems to imply that the subroutine is evaluated in scalar context in the first assignment.

It is.
Scalar assignment evaluates both its LHS and RHS in scalar context.
List assignment evaluates both its LHS and RHS in list context.

Comment on Re^11: chopping a string into slices - is there a more elegant way to do it?

Replies are listed 'Best First'.
Re^12: chopping a string into slices - is there a more elegant way to do it? by gwadej (Chaplain) on Nov 30, 2008 at 22:46 UTC
Okay, obviously I'm about to learn something important here. Because, at first glance, it sounds like you've just asserted two mutually exclusive things. Assignment always evaluates arguments in list context. Scalar and list assignment provide different contexts. Reading further up the comment chain, you are saying that the parens on the left change which assignment operation is used and that is what determines the context. Do I understand this correctly? I went to Programming Perl (3rd edition) to check what I remembered. In Chapter 3, in the section "Assignment Operators", it explicitly says: List assignment may be done only with the plain assignment operator, =. In list context, list assignment returns the list of new values just as scalar assignment does. This talks about the context in which `=` is evaluated, but says nothing about how the arguments are evaluated. This may be the source of my (and others) confusion. So, just to be clear, you are saying that the parens on the left of the =, just like a list on the left, trigger the use of the list assignment, correct? I'm still a little fuzzy on how that makes both sides always evaluate in list context. Bear with me on this, I feel like I'm missing something fundamental. I've been working with Perl for a very long time now and thought I understood this point. G. Wade	[reply] [d/l]
Re^13: chopping a string into slices - is there a more elegant way to do it? by ikegami (Patriarch) on Dec 01, 2008 at 02:37 UTC
it sounds like you've just asserted two mutually exclusive things. 1. Assignment always evaluates arguments in list context. 2. Scalar and list assignment provide different contexts. Point 1 is a misquote. I said "the aassign operator unconditionally evaluates its operands in list context". "aassign" is short for "list assignment operator". I defined "aassign" earlier on, but I now recognize it hard to distinguish it from "assign" visually. Reading further up the comment chain, you are saying that the parens on the left change which assignment operation is used and that is what determines the context. Do I understand this correctly? Yes. Re^10: chopping a string into slices - is there a more elegant way to do it? shows this. This talks about the context in which = is evaluated, but says nothing about how the arguments are evaluated. This may be the source of my (and others) confusion. Re^10: chopping a string into slices - is there a more elegant way to do it? describes the two operations in detail. So, just to be clear, you are saying that the parens on the left of the =, just like a list on the left, trigger the use of the list assignment, correct? Yes. A hash or an array would also do that. `$a= scalar assign f()= scalar assign @a= list assign %a= list assign (EXPR,...)= list assign (EXPR)= list assign ()= list assign` [download]	[reply] [d/l]
Re^14: chopping a string into slices - is there a more elegant way to do it? by gwadej (Chaplain) on Dec 01, 2008 at 02:42 UTC
The other thread actually made it clear for me. The point that the assignment operator (aassign or sassign) was chosen at compile time had escaped me before this point. Thanks for taking the time to clear this up. It's a little corner that I had not previously peeked into and I now understand a little more. G. Wade	[reply]