In the case of grep, you're not assigning a list to anything. What you're assigning to the scalar is the return value from grep, which will be a list in list context and a scalar in scalar context.

s/grep/a slice/g above and it all is precisely as true as it was before the substitution.

I fail to see how the scalar return value from grep when called in scalar context is equivalent to the list returned by a slice.

Swap "grep" with "a slice" with each other above and it is just as true: I fail to see how the scalar return value from a slice when called in scalar context is equivalent to the list returned by grep.

To be fair to FunkyMonk, there was nothing said about everything that can in any circumstance always returning the list last item of a list it took as an argument in scalar context.

Yes, but s/said/implied/ and then you'd be dead wrong. What was said was that "X returns Y and Y does Z" as explanation of for why "X does Z". That only makes logical sense if "X returns Y" implies that "X does Z" which only makes sense if the "Y does Z" phrase really meant "Y always does Z" or "every Y does Z".

And it makes even less sense when this is adjacent to the mention of how W if different and it is pretty clear that "W returns Y" in exactly the same sense as "X returns Y".

You seem to hold the mistaken impression that a slice (any of the three types of slice) is fundamentally different from grep and map. Each type of slice only returns a list when in list context and each type of slice makes a(n independent) choice about what to return when in scalar context, exactly like grep and map. (And the optimization done to map and/or grep with Perl 5.010 certainly has nothing to do with what anything chooses to return in scalar context.)

I'll agree the wording was potentially misleading. I didn't read it to mean what it could have been read to mean, as I didn't make any assumptions about "always" or assume any implied meaning. It would be easy to read more than face value into that text. I didn't, BTW, s/said/implied and I really meant exactly "said" in that case. I know I'm not always so precise, but this time I was. That's one of the problems with natural language.

A slice does make that same return decision based on context, but that's at the implementation level. At the language level the description can usually be abstracted away, because there is no simple way to redefine the return behavior of the slice from Perl. What they return in scalar context is effectively fixed unless you're pulling dirty tricks on your code's next maintainer.

Subroutines can easily be changed to care or not care about the calling context and to do different things if they care (or even based on the caller or other things more esoteric than the context) at the Perl level. Named built-in procedures look and act like more like subs than variable accesses do. Therefore, it's often easier to explain them in terms of Perl-level behavior of subs than C-level behavior of RHS and LHS in the interpreter.

Speaking of contexts, human conversation has context, too. A big part of that context is the abstraction level of the concepts involved. For effective communication, one usually doesn't intermingle abstraction levels without delineating them. If you choose to abstract slice accesses differently than FunkyMonk, then that's fair. I think you're intermingling the Perl language level with how perl does Perl under the hood in the middle of a language-level a bit differently than some other people in the thread are. Once they come to understand what you're actually discussing or you agree to write about what they are actually discussing, then it'll be easier for everyone to be clear and save everyone some headaches.

I'm not going to arbitrate which level is more suitable or which abstraction at the language level for slices (the one that more closely matches the implementation or the one that's IMO frankly clearer to people coming from a C-like language POV) is a better way to present the idea. I think it may be fruitful for the participants of the thread to recognize that the whole thread is a muddled mess of conflicting descriptions from different levels which eventually could be understood the same way. Different readers will understand one better than the other, but it's easier once both are put forward if the differences between them are made apparent.

You have "mischief" in your name and mischievious people are often just full of bull. But just read that at face value and surely you won't draw any crazy conclusions like it was meant to imply anything about you. After all, it doesn't say anything about you (other than an obviously correct obdervation about an aspect of your monk name).

I didn't say nor imply that you said nor meant "imply". You objected to my argument. Your objection was strictly correct because of the use of "say" (which meant "explicity write", of course) but I still assert that your objection lacks merit, just like my first paragraph lacks merit. And I stand by my response that it makes little sense to defend the initial writing via, in effect, "It doesn't actually say anything that is wrong. It just says some things that are fine if you completely ignore that they were said together". (After all, "human conversation has context, too".)

grep isn't a sub. It is a built-in feature of the language just like slices are. Some built-ins can be overridden in various ways. It is exactly as easy to change what the built-in grep returns in a scalar context as it is to change what the built-in hash slice returns in a scalar context (by changing the C code that implements those built-ins).

I don't see how the difficulty involved in replacing a particular built-in is anything other than a serious departure from the topic at hand. Surely the decision about what these built-ins were implemented to return in scalar context was not impacted by how easily it might one day become to replace a built-in with something else. Neither of those built-ins could be replaced by the user when those decisions where made.

Perhaps you need to add "list assignment" to your mental model here. It is at least as "not a subroutine" as "list slice" and also "returns a list" (and you certainly have to construct a list for a "list assignment" to happen). So surely it must just behave like a list? Of course, it doesn't return the last item when evaluated in a scalar context (and this is quite important).

I think what I'm advocating and trying to describe is a much, much simpler model of Perl and contexts than you appear to be working with. Every operation in Perl has the potential to return something different based on context. I'm not trying to build some (artificial) destinction between things that can choose and things that I don't have to think about what the choice was.

At the language level, a choice had to be made for what a list slice would return in a scalar context. I didn't really bring up implementation details, BrowserUk did (though the implementation details didn't support his argument which he eventually abandoned, choosing to impune my writing style instead).

I did note that one of these choices had not yet been implemented (a long time ago), but that wasn't about details about how things are implemented. It was to note that the decision hadn't even been made yet (and because I find it humorous, especially because of how I discovered that I had implemented it, which I won't go into).

And, again, if it were just a semantic argument, then I wouldn't be wasting any time on it.

I (rarely) counter the "X is a list and so it returns the last item" meme, because at a language level it leads to wrong conclusions. Because I've seen multiple instances of people (explicitly) stating things that are actually incorrect that they believed to be true because they used the "X is a list and so it returns the last item" meme. It usually doesn't lead to wrong conclusions right away (which is why it is such a successful meme).

- tye