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])implied (but did not document) that these two constructs should be the same to the point of neither one wastefully generating a list when used in a scalar context. And I thought the implementation would be smart enough to not even generate the list of subscripts (much less generate the list of values). To do this, the operations that would generate the list of subscripts need to know that they don't need to do this work.
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]
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])which it (currently) isn't.
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);[...]
and why these two don't return the same values when used in a scalar context? - tye (but my friends call me "Tye")# same as map assignment above %map = ('red',0x00f,'blue',0x0f0,'green',0xf00);
In reply to (tye)Re4: Hash slices ?
by tye
in thread Hash slices ?
by ChOas
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |