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
In reply to Re^10: Scalar context of slice (vs grep)
by tye
in thread Scalar context of slice
by thenaz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |