Secondly, I know that infix operators could very well be rewritten as prefix or even as postfix operators or as prefix functions. That's not what is being discussed here.

As I've said before, and I always tend to have to say when discussing this topic: I think there's merit in giving people pointers to an abstraction that is clearer to you, but that if they find an abstraction you find inferior clearer to them then why must you attack that abstraction?

I think both ways of looking at this can be helpful. I think some people learn better by digging deeper and figuring out what happens at the lower level sooner. I think others prefer to learn a few rules and to learn convoluted exceptions. I really do think some people learn better that way. In fact, in many fields of endeavor people are taught first approximations of ideas, then exceptions, and later taught completely different ways of thinking about the same things.

"'i' before 'i' except after 'c', except when it's an 'a' like in 'neighbor' and 'weigh'" ... except when it's not. Do you really expect kids just learning to spell to know which words are from French, German, Latin, and Greek roots? Irregular plural nouns are taught similarly. Gee, if only there was a programming language that was written by a linguist and could be learned piecemeal like a natural language...

if they find an abstraction you find inferior clearer to them then why must you attack that abstraction?

Where have I done this? Did you mean "Why must one attack"? I asked a couple of questions to try to understand the abstraction, and the only thing I've done since then is answering questions that were posed.

Secondly, I know that infix operators could very well be rewritten as prefix or even as postfix operators or as prefix functions. That's not what is being discussed here.

I didn't rewrite anything or discuss rewriting anything. I simply posted a representation of the opcode tree. list and aassign (list assignment) actually exist in the tree. And yes, the args of aassign are in the reverse order that they appear in the code.

I think both ways of looking at this can be helpful.

I agree. That's why I asked question to better understand.

Before the last discussion on the topic, I would have said there's no such thing as a list in scalar context. The discussion resulted in learning that using the word list is problematic since it means too many different related things.

I think some people learn better by digging deeper and figuring out what happens at the lower level sooner. I think others prefer to learn a few rules and to learn convoluted exceptions.

What about a few rules without any exceptions?

• An operator imposes a context on its operands.
• Every operator decides what it returns based on context.
• An operator cannot return a list in scalar context.

There are no exceptions to the first two rules. Any exceptions to the third rule will crash Perl.

You can use heuristics to determine what a particular operator returns in scalar context (the last element "except after 'c'"). This is where the learning method you mentioned applies. But trying to rewrite those three base rules has so far resulted in a 18 post deep thread of questions.

The problem is not about what happens, which is eminently described by your rules.

The problem is how to discuss what happens and why, without complex ascii-art diagrams, or multiply subscripted essays, for the two common results of symbolic (source code) expressions that appear (conceptually) to produce multiple values, when those constructs occur (directly or indirectly) in a scalar context. Namely:

1. They result in a scalar that is the number of those multiple values that would have been produce had that same construct appeared in a list context.

   @a = 'a'..'d';;
   
   print @a;;
   a b c d
   
   print scalar @a;;
   4
   [download]

2. They result in a scalar that is 'last' value of the multiple scalars that would have been produced had the same expression appeared in a list context.

   print('a'..'d');;
   a b c d
   
   print scalar ('a','b','c','d');;
   d
   [download]

In the context of the original thread, the question was asked: Why does a slice @a[0..$#a] produce a different result in a scalar context to the array, when they both produce identical results in a list context. (Or meaning to that effect.)

And the reply (with licence), that started this discussion, was: Because a slice acts like a list in a scalar context.

The problem that arises is that people, (those in the know), will insist on taking that use of the word 'list' to mean some ethereal, maybe-exists or maybe-doesn't, internal state; rather than the more general, more useful, concrete concept of what has (in at least one post) been alternatively named a 'list constant'.

So, in order to be able to discuss and relate to discussion, and to be able to categorise the effects of the many constructs in a scalar context, the following two phrases might be used to relate any given expression to the well known and broadly understood situations in 1 & 2 above:

1. The result of expression X in a scalar context, will be a count of the items in the list produced where that same expression appears in a list context. Similar in effect, to when an array expression appears in a scalar context.
2. The result of expression X in a scalar context, will be the last item from the list that would have been produced where that same expression appears in a list context. Similar in effect, to when a list (constant) appears in a scalar context.

And those two wordy (and I hope inarguably accurate:), phrases should be replacable by:

1. In a scalar context, expression X acts similarly to an array expression.
2. In a scalar context, expression X acts similarly to a list (constant).

In turn, if people would accept that in the context[sic] of posts like the one that started this saga, that the term 'list' is most likely to mean the concrete variety, rather than the nebulous, ethereal source divers-only meaning, then the phrase "It acts like a list in a scalar context", is a simple, convenient and conceptually accurate way of describing what happens when (for example), an array slice expression appears in a scalar context.

For me, the crux of this whole saga is that attempt by certain somebodies to infer a meaning from the use of the term 'list' that simple doesn't appear on the horizons of most SoPWs; nor even the greater majority of Perlers. And then jump on people because of that (wrong) inference.

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

• An operator imposes a context on its operands.
• Every operator decides what it returns based on context.
• An operator cannot return a list in scalar context.

Allow me to have those numbered for clearer reference:
1. An operator imposes a context on its operands.
2. Every operator decides what it returns based on context.
3. An operator cannot return a list in scalar context.
I think part of the problem with saying this is only three rules is that we're using what appears to be a mathematical representation but with slightly incompatible CS jargon. In CS jargon, the ($x,y) = ($foo, $bar) has one operator and two operands (both of which are groups of scalars (or "lists", if I may with JavaFan's permission used that term in its English definition. Yet in mathematics the words "operand" and "result" are not used quite the same as what rule #1 assumes. It fully appears to the naive that what we have there is a list as a result on the left, an operator in the middle, and a list as an operand on the right. That of course is not strictly what is happening, but you must clear up that misconception (rule 0, perhaps) before rule #1 hits its mark.

Be prepared for questions of infix, prefix, and postfix forms, of arity, of precedence of the assignment operators, and of associativity. Be prepared for when someone asks if the commutative, associative, and distributive properties apply to assignment. When the syntactic sugar makes something appear to be mathematical and you must point out that it is only closely related, people will come up with all sorts of odd questions to confirm what can be inferred from math to the language.

I don't see how someone who's not a CS student or graduate gets either abstraction for free. Many of the people who program in Perl have studied little CS, have studied it informally, or have studied none of it at all. If they already have taught themselves along one line of thinking, which happens to be the one the docs seem to reinforce, then asking them to throw that away in favor of what's easier for someone already trained in CS might be asking a bit much.

The abstraction you present may help someone more in the long run, and probably will if they ever dig that deeply. It may turn them off the language completely in the short term, though, or delay their study of the particular topic. If they learn to think about it in a way that lets them write software and can change how they think about it later, I do not see the harm. The biggest complaints I've seen against the approach FunkyMonk took in Re: Scalar context of slice to explaining this situation in Perl is that it can be potentially misleading and that it can waste time to learn something more than once in different terms. I'm not sure either is such a terrible thing. Waiting to understand the actual way it happens inside perl might waste time, too.

I would rather encourage someone to learn whichever explanation makes more sense to them, with the caveat that one (the "simple" one) requires more information beforehand and the other one (the "complex" one) requires even more of the same rule and exception handling later.