Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Hash slices ?

by kilinrax (Deacon)
on Dec 01, 2000 at 17:30 UTC ( #44337=note: print w/ replies, xml ) Need Help??

in reply to Hash slices ?

Adding a couple more tests to your script gives us a clue:

@keys = qw(one two five); unshift @keys,'four'; print "@keys\n"; if (@hash{@keys}) { print "yep\n"; } else { print "nope\n"; } @keys = qw(one two five); push @keys, 'two'; print "@keys\n"; if (@hash{@keys}) { print "yep\n"; } else { print "nope\n"; }
Gives the result:
four one two five yep one two five two nope
It would appear that only the presence of the last key in the array is affecting whether the test returns true or false.

I would suggest a possible solution would be to abuse grep, thus:
if ( grep{ exists( $hash{$_} ) } @keys ) { print "yep\n"; } else { print "nope\n"; }

Comment on Re: Hash slices ?
Select or Download Code
Re: Re: Hash slices ?
by snax (Friar) on Dec 01, 2000 at 17:45 UTC







      "Perl makes the fun jobs fun
      and the boring jobs bearable" - me


        But I was thinking about that already before I thought of
        the slice ;))
      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

        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.

        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?"

        Brainbench 'Most Valuable Professional' for Perl

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://44337]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (13)
As of 2014-12-27 17:16 GMT
Find Nodes?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?

    Results (177 votes), past polls