Actually, there are lots of ways to tell those apart. I've mentioned a few (did you read (tye)Re4: List context or not? that I mentioned in my update above?).

I'm glad that you could "guess" what would happen in a scalar context. But I thought you said that it is documented? You have quite an interesting definition of "documented" if it includes "guess" in the process.

You also bring up an important concept in Perl: That the use of a scalar context should prevent an operation from wasting the time and/or space of generating a whole list of values.

To me

@days[3,4,5]   # same as ($days[3],$days[4],$days[5])

So that documentation implied to me that the context in which an array slice is used would be "passed inside" the brackets to the code for the subscripts (just like how the context in which a function is called gets "passed inside" to the code for the return value).

And for the example given, you can't tell that this isn't what was happening since all of the following return the same value:

    scalar( @days[3,4,5] )
    @days[ scalar( 3,4,5 ) ]
    scalar( ($days[3],$days[4],$days[5]) )
    $days[5]
[download]

Unfortunately, that optimization has not been implemented. If it were, then the following would also be true:

@days[3,4,@a]   # same as ($days[3],$days[4],$days[@a])

So now I can tell you that I find that your apparent definition of the term "documented" is, frankly, poppycock. The most I'd be willing to admit is that the behavior of an array slice in a scalar context is "hinted at in the documentation", but I consider even that a stretch.

Which is why the documentation did not so document the case which is not the same in scalar context!

Well, that is an interesting assertion. I won't believe it unless you can find the author of the section and convince me that they actually recall making that conscious decision.

My guess was actually that the words "same as" were omitted in that case simply because that would make the comment long enough that it might wrap and ruin the format of the example!

Perhaps you should post PSI::ESP::Pod to CPAN. q-:

Finally, if "same as" in comments of example code is supposed to mean "same to the point of returning the same value in a scalar context", then please explain, from the same perldata.pod:

($map{'red'}, $map{'blue'}, $map{'green'}) = (0x00f, 0x0f0, 0xf00);

# same as map assignment above
%map = ('red',0x00f,'blue',0x0f0,'green',0xf00);
[download]

Your expectations make no sense to me here.

First of all when I read documentation I assume that the person writing it knew what they were saying. I constantly test what they are saying, but what I am testing is (in an ideal world) my comprehension of what they are saying and not the correctness of what was said. If one thing does not say "the same as" and 2 presented beside it do, that difference is likely to not be an accident and deserves analysis.

Secondly before jumping to beliefs, sanity check them. For instance you say that you look at that example and thought that the context should pass through to the inside to the last argument. But in that case then .. in that example would be the flip-flop operator, not the range operator. However it gives a range, therefore the context is not passed through. In other words there is no way that what you describe as wanting could possibly be what is documented there!

Thirdly my experience with the Perl documentation is that it is very carefully written. Take, for instance, the example that you point to and ask me to explain. Well what does it say? It says, same as map assignment above. It does not say that the construct is the same, it says that the assignment is the same. Now one of the key points about context is that what is being assigned to on the LHS sets the context for the RHS. In other words the context in which the assignment is happening is part of the assignment. Given that I fail to see how it is relevant to the rest of this discussion.

Now you want me to produce PSI::ESP::Pod? Well we both know that is a joke, but here are a few principles that it would include:

1. The Perl documentation was written by people who know their subject well and do their best to be careful about how they say things. It is generally unwise to assume they omitted something by accident. It was generally omitted on purpose, and by trying to figure out what tangent they tried to avoid discussing you will often notice interesting things.
2. The Perl documentation deserves to be re-read. Upon re-reading you will notice things that you missed before. The same thing goes for reading books written by the people who wrote that documentation.
3. Details of the wording tend to be very significant. Do not read it like you would normal sloppy speech. Far more thought and energy went into documentation than we normally put into what we say.
4. Generally it is safe to assume that constructs fit into categories that have already been explained. For instance in perldata it explains that the two major contexts are list and scalar and explains the division. Unless further clarification is made, it is safe to assume that any construct you see will fall fairly cleanly into this classification.
5. It is helpful to not think in terms of the implementation, but rather to try to form a sense of how Larry thinks. One thing that he has claimed, which I can well believe, is that his thought process is rather messy but he is very good at synthesis later. In that case there are cracks, they show, but there are also guiding principles. Learn the exceptions, but try to find and keep those principles clear. (This is called "trying to read Larry's mind.")
6. (Unfortunately) it is often the case that sections of the documentation try to say so much in so little space that it is more useful for confirming what you already know than it is for learning from. That is life.
Now applying those principles to the section under discussion, what do we get? We get that 2 out of 3 constructs are the same but the third is probably different. Since we know from elsewhere that the way that the others are expanded is different in scalar context, we have a pretty good idea what was not discussed. Since the principle that things generally fall into scalar and list context has been laid out and is key, from the example given we can take it that the arguments to the slice are in list context because we are getting the range operator rather than a flip-flop.

Given what we know about list context, you should now have clear expectations about what happens if, for instance, you put function calls in that argument list. They will not be optimized away, but they will be called, and they will be called in list context. The return values will not show, but side-effects will.

Now none of this is laid out explicitly. Indeed if you were not reading carefully, paying close attention to wording you would miss it. However if you know it and go back to the documentation, it really is there. Don't take shortcuts. Don't make up absurd theories. Don't form parallels to other (just as carefully worded) sections in trying to misunderstand. It is there.

Of course for most people it is only going to be useful if they already know it and therefore can make educated guesses about why things were phrased as they were.

But what merlyn said is not poppycock.

I am loath to even reply, so I'll try to keep it short.

There is no .. in the examples we have been discussing. I see a few elipses that look like Perl's ... operator but that clearly aren't meant as range nor flip-flop operators in that setting.

One of the examples has elipses while the other two don't. Are we supposed to draw some deep conclusion about the reasoning behind that? Two of the examples are short and one is long. I have an "absurd theory" that the long example has an elipsis and is missing the "same as" for the same reason: because it is long and forcing a line wrap would reduce the readability.

I did a quick search to see if I could turn up previous discussions about the fact that many details of Perl's behavior are intentionally not documented. The basic idea is that some behaviors aren't particularly important and it is good to leave things open in case later optimizations or enhancements change these "edge" behaviors (intentionally or accidentally). Unfortunately, old Usenet isn't well archived (or at least indexed and available to me) at the moment.

The behavior of an array slice in a scalar context seems a quite reasonable example of such to me. Reading the code, I get the impression that the current behavior is more an afterthought during implementation than a careful design decision. (Not to mention the fact that it isn't documented anywhere [*cackle*].)

But anyway, the interesting bit about the search was that it turned up this:

NETaa13671: array slice misbehaved in a scalar context
From: Tye McQueen
Files patched: pp.c
 A spurious else prevented the scalar-context-handling code from running.

which I got a good chuckle out of. Apparently, long ago, I actually patched Perl to fix "array slices in a scalar context" (I haven't yet been able to summon a memory of this). Anyway, I thought that was pretty funny. (:

So it is possible that array slices in a scalar context didn't even "work" before I came along.

Looking at a modern Perl (5.6.0) I see no tests for the behavior of an array slice in a scalar context (more evidence, to my mind, that this is considered an "edge" case).

But none of this matters much. You have been completely unswayed by all of my erudite elocutions while I find your "absurd" and elaborate theories about how to claim that this simple behavior is (magically, implicitly) "documented" increasingly comical. q-: (You may have to read that with a good, pompous tone of voice to get the silliness of it.)

That is to say, we aren't getting anywhere so let's just stop! I know I'm quite tired of it and I suspect that most (if there are any) of those that have read this far are getting tired of it as well.

        - tye (but my friends call me "Tye")