in reply to Re: Hash slices ? in thread Hash slices ?
Ayup -- it's the last key that matters, just as if
the hash slice were being treated as a list -- evaluate
a list in a scalar context and it returns the last value.
There's nothing in the docs that I could find that says
that a hash slice would be interpreted as a list rather
than a proper array, but it does apear to be the case.
Re: Re: Re: Hash slices ?
by davorg (Chancellor) on Dec 01, 2000 at 17:53 UTC
|
Any one further investigation, it seems that my
original solution suffered from a fundamental problem.
my %hash = (one => 1, two => 2, three => 3);
my @keys = qw(four five six);
my @slice = @hash{@keys};
@slice is now contains four undef elements,
where I thought it would be an empty list (don't know
why I thought that - it was very early in the
morning.
If the hash slice was interpreted as an array, it would
therefore always be true and therefore doesn't
solve ChOas' original problem. That would be better
addressed using something like:
if (grep { exists %hash{$_} } @keys) {
print "yep\n";
} else {
print "nope\n";
}
--
<http://www.dave.org.uk>
"Perl makes the fun jobs fun
and the boring jobs bearable" - me
| [reply] [d/l] [select] |
|
perl -w -e '%x=(a=>7,b=>8,c=>9);@s=(qq(a),qq(b));$y=@x{@s};print $y;'
returns 8 -- so it is pretty clearly the case that
a hash slice is properly a list.
| [reply] [d/l] |
|
I was thinking about doing it like this to avoid the grep:
sub Match{foreach (@keys) {return 1 if exists $hash{$_};}return 0}
if ( Match )
{
print "yep\n";
} else {
print "nope\n";
};
But I was thinking about that already before I thought of
the slice ;))
| [reply] [d/l] |
Re: Re: Re: Hash slices ?
by merlyn (Sage) on Dec 01, 2000 at 20:14 UTC
|
Well, we always go around about this, because the perldata does clearly say:
@days # ($days[0], $days[1],... $days[n])
@days[3,4,5] # same as @days[3..5]
@days{'a','c'} # same as ($days{'a'},$days{'c'})
See the "same as"? That's the operative words. To make it the same, it has to
return the last element of the list in a scalar context. So yes, the behavior
is documented, and derivable from the docs.
-- Randal L. Schwartz, Perl hacker | [reply] [d/l] |
|
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})
or even these:
@days{foo(),bar()}
($days{foo()},$days{bar()})
when in fact, they aren't.
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;
}
unlike many "list-returning operations" that know to optimize their behavior in the face of scalar context. And all of this has very little to do with the comma operator which you claim it is "documented" as being "same as".
-
tye
(but my friends call me "Tye") | [reply] [d/l] [select] |
|
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.
| [reply] |
|
|
|
|
First, thanks for your comment.
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.
| [reply] |
|
True, it is derivable from the docs. Having just
finished a conversation with a co-worker about another
nearly undocumented feature of Perl, I find myself just a
bit frustrated with these "derivable" documentation
tidbits.
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
| [reply] |
|
|