Poppycock! That is such an outrageous statement I don't really know where to start.

If we are to take "same as" in some comment in some sample code and extrapolate fundamental behavior from it... So since "same as" has such profound meaning, then it must also be true that these two are "the same":

@days{@x,@y}
($days{@x},$days{@y})
[download]

@days{foo(),bar()}
($days{foo()},$days{bar()})
[download]

The fact is that a hash slice in a scalar context returns the last item of the hash slice because there is C code that specifically does that. What you quoted doesn't qualify as documentation of that fact. If that is the only documentation, then it is undocumented.

In fact, Perl actually goes though and builds the entire list result of the hash slice and then moves the last item to the front:

    if (GIMME != G_ARRAY) {
        MARK = ORIGMARK;
        *++MARK = *SP;
        SP = MARK;
    }
[download]

There is a significant and important difference between how you are supposed to think about things and what goes on under the hood.

merlyn is absolutely right about what concepts Perl's behaviour is intended to give. You are absolutely right about the implementation. It is both possible and likely that a future implementation will render your observation incorrect. It is much less likely that the concept both merlyn and perldata are trying to convey will be invalidated at a future point.

Therefore I like merlyn's answer and do not consider it, implementation trivia notwithstanding, poppycock.

*Sigh* It appears that you are mixing threads here. I didn't call "poppycock" any assertion by merlyn about "what concepts Perl's behavior is intended to give". I called "poppycock" his claim that "same as" is a reasonable way of documenting "same as, to the point of returning the same things when used in a scalar context".

Update: See (tye)Re4: List context or not? for a better argument on this.

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

Now, on to what I originally wrote, which may sound snippy -- it's not meant to be.

Right. Well. That's a bit cryptic, though, no?

Further, 2nd Ed of Programming Perl provides that the first line is "Same as" as well. I'm not here to nitpick about right or wrong, though. Perhaps a line in perldata someplace that says "hash slices are lists" would clear things up.

Honestly, I find this behavior a bit odd. With a list, evaluated in a scalar context so that it returns its last value, you could at least have things going on prior to the last value that are meaningful in determining the last value (much like constructs in C with the comma operator).

By the time you shove stuff into an array, or hash, and then pull out a slice, it makes more sense to me for this to be more "array like" than "list like"; the values before the last one are then in the dreaded void context if this object is then evaluated in a scalar context.

That is definitely enough musing from me about what is, to me, a very dusty little corner of perl.

The difference between arrays and lists can be pretty esoteric. In this case, it takes a pre-existing understanding of the list vs. array issue to decode the docs.

As a frequent Perl mentor, I often answer this type of question. Where can I find a good reference that will point out issues like this? Effective Perl Programming is a fantastic "up-and-coming-Perl-coder" book. It doesn't seem to address this lists vs. array issue, however. Are there any other good intermediate-level books which cover this kind of "gotcha?"

Russ
Brainbench 'Most Valuable Professional' for Perl