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

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

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
March 30, 2013 07:05
Subject:
Re: Perlfunc for each(), keys(), values() has been changed
Message ID:
20130330070509.GA32730@fernweh.plasmasturm.org
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2013-03-29 19:20]:
> * demerphq <demerphq@gmail.com> [2013-03-29 18:30]:
> > On 29 March 2013 18:06, Aristotle Pagaltzis <pagaltzis@gmx.de> 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, 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.

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.

But to say that it talks about implementation specifics just because it
talks about “is” is nonsense, and I take that back.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About