develooper Front page | perl.perl5.porters | Postings from March 2013

Re: Perlfunc for each(), keys(), values() has been changed

Thread Previous | Thread Next
March 30, 2013 16:46
Re: Perlfunc for each(), keys(), values() has been changed
Message ID:
On 30 March 2013 08:05, Aristotle Pagaltzis <> wrote:
> * Aristotle Pagaltzis <> [2013-03-29 19:20]:
>> * demerphq <> [2013-03-29 18:30]:
>> > On 29 March 2013 18:06, Aristotle Pagaltzis <> wrote:
>> > > IMO this mentions too many specifics of the current
>> > > implementation’s behaviour – it would require revision the next
>> > > time the hashing changes.
>> >
>> > Such as? (Honest question.)
>> I don’t know… but then that is the point. :-) Maybe there will be some
>> currently unfathomable reason to make sets of hashes sharing a seed or
>> something… doubtful of course, but I don’t think I will be able to
>> come up with an example until it happens, if it ever does. The thing
>> is, it *may* be read as promising something that p5p *may* want to
>> change later, and at the same time I do not see any counterbalancing
>> value to the programmer in explaining to them these specifics. It’s
>> more useful to both sides to emphasise Perl’s explicit promises and
>> leave everything else open.
> Actually I see now that I misread this question and didn’t answer it.
> The statement that gave me my mistaken impression was “The actual random
> order is specific to a given hash; the exact same series of operations
> on two hashes may result in a different order for each hash.” Now I know
> you are talking about the hash seed here,

No, actually I am not. I am talking about the iterator randomizer
combined with the hash seed.

IOW, even with the hash seed fixed you can expect a different order
for every hash, regardless if the exact same series of operations were
performed on the structure:

$ PERL_HASH_SEED=0 ./perl -le'%h1=("A".."Z"); %h2=("A".."Z"); print
keys %$_ for \%h1, \%h2'
$ PERL_HASH_SEED=0 ./perl -le'%h1=("A".."Z"); %h2=("A".."Z"); print
keys %$_ for \%h1, \%h2'

> but that is my reading of it;
> there is no actual mention of that in the text. In fact, as I already
> said in my above attempt at an answer, it is hard to imagine whatsoever
> future implementation of hashes to which this statement would not apply.

It means exactly what it says, every individual hash has its own
keyorder. This is not true in older perl's; two hashes with the same
"insert history" would have the same structure and key order. In 5.18
this wont be true.

> The real reason I am uncomfortable with that statement is that its focus
> is on how hashes work rather than on what semantics they are *intended*
> to provide – put another way, it talks about “is” rather than “ought”;
> and you cannot derive “ought” from “is” so I felt it ought to talk about
> “ought” instead.

The intention was to define things in such a way that it allows the
widest range of implementations.

I tried to define everything in terms of what a user can expect.

For example I said "repeatedly" because i want it to be clear that this:

@k1= keys %hash;
@k2= keys %hash;
is "@k1","@k2";

will always pass. But the rest is worded such that it should be clear that this:

@k1= grep $_ ne "thing", keys %hash;
delete $hash{thing};
@k2= keys %hash;
is "@k1","@k2";

is not guaranteed to pass (it may or may not -- currently it would,
but it needn't).

If my wording needs help I'm open to further rewrites.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About