Front page | perl.perl5.porters |
Postings from March 2013
Re: [perl #117271] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz
From: Deven T. Corzine
March 21, 2013 19:00
Re: [perl #117271] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz
Message ID: CAFVdu0Qrz+mT9boOsfR=tchW-Sc8xEOyNft5Emb9n55QAKohQA@mail.gmail.com
I'll probably regret responding at all, but here goes... Yes, I've read
this entire thread already. I'll try to leave out as much as I can...
On Thu, Mar 21, 2013 at 1:04 PM, email@example.com <
> I just looked up the meaning of "same" at thefreedictionary.com.
> First meaning it lists is "identical".
> Second meaning it lists is "similar in kind, quality, quantity, or degree".
> (there are two more).
Just because a word has multiple meanings does not make them synonymous.
The context makes it fairly obvious that the "same hash" means the same
underlying data structure, not similar ones. Yes, your interpretation is
plausible given the possible meanings of "same", but most programmers would
interpret the verbiage in the documentation as a very clear and unambiguous
warning not to rely on the hash ordering in general, except as explicitly
> Or you disagree with what "same" means? It seems arguing against
dictionaries is unproductive, though, it leads nowhere (except you being
> wrong in this case, but it's still pointless...).
Who is arguing against the dictionary? The documentation used "same" in
its first meaning of "identical"; the other possible meanings of the word
> > returns items in a different order than
> > values(%hash)
> > does then please file a bug.
> So suddenly it is consistent. This is all very confusing to me.
This is a clearly-supported exception to the general rule that you
shouldn't rely on the hash ordering. And I don't think you're confused on
this point at all, you just don't like the answer you've been given.
> > I know how it's meant, but I also know what is said, and assuming that
> > > "the same hash will result in the same ordering" is not unreasonable.
> > The docs say "the same hash unmodified", so that implies very strongly
> > that it means identity.
> Well, not to me, and the other person I asked (I am too lazy to ask a
> bigger control group, sorry).
Let me add to your control group, then. I would say that the context very
strongly implies "identical" even *without* mentioning "unmodified". The
"unmodified" is a further warning that you can no longer rely on any
consistency in the hash ordering after making ANY change to it, and that
adding a new key to the hash might completely resequence the ordering in
any arbitrary way.
> > Saying it changes in future versions but is the same for the same hash
> > STRONGLY implies that the ordering is the same for the same version of
> > > perl, which is already not true.
> > No it doesn't.
> Why mention it at all then? If the ordering is randomly changing, then why
> mention it might change in future versions? It frankly makes no sense.
It makes perfect sense. The documentation reserved the right for Perl to
change the underlying hash implementation at any time for any reason, as
long as the supported use cases remained supported. It was quite clearly
warning not to rely on current behavior.
> >> perlfunc.pod didnt exist prior to that commit.
> > > And it clearly changed, if you took notice.
> > Not in any way relevant to this discussion, if you took notice.
> Your point being that it is a documentation bug, that the existing
> documentation is ambiguous or what?
The oldest quoted documentation was somewhat ambiguous, and it was
clarified fairly quickly. What you can and can't rely on in the semantics
of hash ordering have been quite clear for 15 years now.
I am not claiming your patch breaks documented behaviour (for every
> interprettation). I am claiming the code in question doesn't rely on
> undocumented behaviour.
Sorry, but there's only one correct interpretation of "same" in the context
of that warning in the documentation. Don't expect to get much traction by
"language lawyering" on this point.
Relying on undocumented behavior would actually be in your favor, since the
behavior of the Perl interpreter is presumed correct in the absence of
documentation to the contrary. If you're relying on similar hashes to
behave the same as identical hashes, then you are ignoring a clear warning
in the documentation and it's only by luck that your code has worked until
> > > You'd have to make the stronger claim that no other interprettaion is
> > > reasonably possible, and I don't think you can, simply because "same",
> > > english, is ambiguous as to whether mean identity or equality.
> > There is nothing here to argue about, you are wrong, and there your
> > interpretation is wrong, and that is all there is to it.
> You seem to be unable to explain why it would be wrong, while I gave ample
Despite the fact that "same" can sometimes mean "similar", in this context,
it clearly meant "identical". You can make the argument, but your
interpretation is still wrong.
Not much further down, you say:
Your interpretation is probably a valid one and I wouldn't gfault you if
> you made assumptions based on it, but after I told you it isn't, whats the
> point of arguing further?
You might want to take your own advice here and give up arguing about the
definition of "same".
Hey, I checked a few dictionaries, and listing "similar" as equal meaning
> to "identical" is the norm.
> Again, you are just claiming english is wrong and you are right. That's...
> well, not very useful.
English is ambiguous. That's the nature of human languages, because the
listener generally has the intelligence to disambiguate between several
possible meanings of a word based on the context in which it is used. Yes,
"identical" and "similar" are both possible meanings of "same", but in
context, the "identical" meaning was clearly the correct interpretation.
> The claim that the same hash results in the same ordering is ambiguous
> w.r.t. the meaning of what "same hash" means.
> Identity is one meaning, but the others are there.
Are you arguing that there's a bug in the hash implementation or a bug in
> There is no reasonable interpretation of
> > the documentation that supports your position.
> There certainly is, I gave it, and ignoring it doesn't make it go away.
You gave a possible interpretation. But if you ask most programmers to
read that entire paragraph and decide which interpretation is more
reasonable, I bet the overwhelming majority would say "identical" is a far
more reasonable interpretation than "similar", in that context.
> > You are rude and insulting in your manner, you should not be surprised
> > when people you communicate with are combative.
> So where was I rude? Where was I insulting?
If you can't see it, that's sad. Bystanders can see it. Yves, by
contrast, comes across as remarkably patient and reasonable, despite
> > > It says the ordering is the same for the same hash.
> > And it is. (So long as you dont modify it by inserting new items.)
> Experiments show you are wrong.
You'll have to prove this assertion to be believed.
> > Changing the hash function doesn't break the code. Changing the hash
> > > function within the same version of perl, and within the same process,
> > > what changes it.
> > We don't change the hash function during the process.
> Well, the observable effects are different, which is the point. You are
> splitting hais a lot again, when it's totalyl unnecessar< because I have
> made explicit what the problem is, namely the breakage of JSON::XS.
Even if Perl did randomly select a different hash function every time you
modify the hash, that would be perfectly valid and consistent with the
documentation. You rely on undefined behavior at your own peril.
> > So if the ordering is really the same for the same hash, within the same
> > > process (using the same perl), then I am indeed totally wrong.
> > >
> > > Is that the case?
> > @keys1= keys %hash;
> > @keys2= keys %hash;
> > will always return identical @keys1 and @keys2 assuming %hash is a
> > "normal" perl hash.
> I call that a consistent ordering, you don't.
This is the sort of consistency that the documentation says you may rely
on. That doesn't mean that hash ordering will be consistent in all the
ways that you want it to be.
I think you have a totally unworkable definition of consistent. At least
> that is clear now, and explains a few things.
> What I mean with consistent is that the ordering is the same, within
And it is. The limits are clear -- if it's the same (identical) hash
object, and you don't modify it, then a consistent ordering will be
returned. Outside those limits (modified hash, similar but not identical
hash), all bets are off. It may be consistent, but it doesn't need to be.
You were warned 15 years ago.
> > The documentation simply does not say what you seem to think it says.
> That's beside the point, you said my interpretation is unreasonable (and
> other things), and I say it was, and gave evidence on why.
> I am also not the only one who interpreted it that way, as evidences by
> the breakage that ensued after both stages of patches in that area.
> That doesn't prove the reasonableness, of course.
I don't know I would go so far as to describe your interpretation of
"similar" as unreasonable, but the correct interpretation of "identical" is
obviously MORE reasonable.
> If it did it would say it explicitly,
> It says it explicitly, but unfortunately, in an ambiguous way.
In context, I don't think it's ambiguous at all. How many people truly
find it confusing?
> I think it should be possible to write correct code by documentation and
> experimenting alone, but we have to have to disagree on that point.
I agree with you on this point. However, the documentation is quite clear
about the limits of relying on hash ordering, and the documentation takes
precedence over experimentation here.
> > But the bug is in the perl core. Nothing I apply can fix that, becasue I
> > > can't apply fixes to the perl core.
> > Excuse me? No the bug is in your code,
> No, it's in the core. It was introduced recently, and apparently by your
> patch (I blindly trust andk here).
Changes to behavior which is explicitly documented as undefined don't
qualify as bugs, even if they break code that relied on that undefined
behavior. If you relied on the hash ordering of similar but not identical
hashes, then the bug is in your code, even if it took this patch to expose
> > expecting to snapshot a serialized hash and have that be the same as
> > some other serialized hash with the same keys.
> I expect the same hash to have same ordering within one program run, yes.
Which definition of "same" are you using here?