Re^10: Scalar context of slice (vs grep)

[tye]

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).

[mr_mischief]

One of the strengths Perl has is that it allows one to make many assumptions at a simple level which may not hold when you dig a little deeper. I know from my history of interacting with you that ETOOMUCHMAGIC -- assuming things that do not remain true -- appears to be one of your pet peeves. Yet I think this is one of those situations in which that's what others are doing, and other than annoying you I'm not sure of the harm.

Rules of thumb can be useful. Newton's model was wrong, too, but it's still useful today except when it's not. We can answer people in the frame of reference they bring and note exceptions to watch for later. Those exceptions will be explained as they arise, and the true model can be explained once it's not so daunting. We can alternatively place the question the person asked to the side and explain that their whole understanding of what question to ask was flawed and why that's the case. The latter is probably more correct, but in many instances the former will be less intimidating.

Larry mentions in his talks that Perl is great because the language and the culture allow people to program in baby talk until they are ready to program in a more sophisticated vocabulary and understanding. I think you're striving against that on the basis that it leads to incorrect assumptions between getting useful work done and learning the true hows and whys of the language. I could be mistaken, but that's how I understand your position right now.

[tye]

Your references to rules of thumb and "baby Perl" would make sense here if we had a simple model that worked okay and I offered a much more complex model that worked better.

I'm not trying to force the whole of Perl into anybody's head. I only just recently brought up one more piece of Perl: list assignment. Before that, I was only talking about the original subject matter, slices and map/grep. And I have yet to see how my proposal is the most complex one. I simply propose that operations choose what to return in a scalar context. I don't add complexities about "this is a list" or "that returns a list" or "these are like subroutines" or "those don't build a list on the stack behind the scenes and so they don't really 'return a list'" or "these can't be easily replaced by user code". So we have several complex models that don't work except for a few cases and a cleaner, simpler model that doesn't run into those problems.

I am pointing out that there is complicated and imprecise baggage being thrown around and some might wish to stop complicating their thinking and explanations and discard it, especially because it will lead them and/or others astray as it has before. A better analogy than Newton or "baby Perl" would be comparing the idea that the world is flat and is held up by four elephants positioned at each corner and those are standing upon a giant turtle vs. the idea that the world is a ball floating in space.

Sure, trying to get the point across to somebody who believes the world is flat isn't as simple as "um, the world is a ball floating in space. got it?" So the explanation of "no, it is simpler than that. really." can take some work and, depending on what arguments are thrown up against it, can get complicated. The difficulty in demonstrating that the simpler explanation is more accurate or even to convey how it is actually simpler is a separate complexity.

I'm not sure of the harm

The harm has been explictly stated and then echoed by you; the idea leads to incorrect conclusions ("which may not hold when you dig a little deeper"), leads to mistaken expectations, confusion, wasted time, etc. That can certainly be an acceptable cost... if there is some gain. The gain in the examples you offer is the gain of much greater simplicity.

other than annoying you

Please don't try to tell me my emotional state based on some text you read that never mentioned emotions. But at least you've made a self-fulling prophecy. You have managed to annoy me now.

I know from my history of interacting with you that ETOOMUCHMAGIC [...] appears to be one of your pet peeves.

I've certainly mentioned ETOOMUCHMAGIC before. But telling me what is a "pet peeve" of mine I also find quite presumptuous and dismissive. I'll also note that your assessment that this is somehow ETOOMUCHMAGIC rather badly misses what I mean when I use that term anyway.

You are certainly free to choose to dismiss what I am trying to explain as a mere emotional response to some pet peeve. What a waste of my time that would be. Somewhere I got the impression that on rare occasions, people would come together to discuss nearly any aspects of Perl in an attempt to better understand it. I wonder where that place was.

[mr_mischief]

I'm sorry for annoying you. You can be annoying to me sometimes, too, both of which are beside the point. I'm sorry for making assumptions about your line of thought, but you've done the same to multiple other people in this very thread^1,5. All of that is beside the point.

The point is that you have what you say is a very simple way to describe the situation. merlyn in the same thread very simply stated that explanation and linked to a pointer in one of his columns. Your nodes have not been simply pointing out that explanation, but actively criticizing the explanations of others. merlyn managed to promote the same view of the problem without all the drama.

You appear -- and I'm trying hard not to assume this so please correct me if my interpretation of your writing is incorrect -- you appear to be saying that anyone on PerlMonks should be assumed to be ready for the most straightforward explanation², and that we should backpedal and teach them how to be ready for that knowledge when explaining things if their personal frame of reference does not prepare them for it. The opposite assumption is being made by others -- that if someone asks a question which appears to be towards a beginner's thinking that one should try to teach the next rule and exception up the chain³. What proof does either side have? Do you have support for the superiority of your stance or the supposed harm done by the other? Are you so sure what you infer⁴ about the concept (sorry, "meme") presented by FunkyMonk is in fact inferred by others and is actually harmful?

Footnotes in the readmore... they discuss the noted issues at a little more depth.

Read more... (5 kB)