[squeak-dev] #= ==> #hash issues

Chris Cunningham cunningham.cb at gmail.com
Fri Nov 2 16:52:37 UTC 2018


Hi Louis,
On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <Lou at keystone-software.com>
wrote:

> Hi Chris,
>
> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
> cunningham.cb at gmail.com> wrote:
>
> >ParcPlace-Digitalk VSE 3.1 (roughly 1999):
> >
> >(0 to: 1) = (0 to: 5/3). "true"
> >(0 to: 1) hash = (0 to: 5/3) hash. "true"
> >
> >So, ancient VSE and current VisualWorks are consistent, and agree on where
> >they want to be.  This is also the direction I want to take Squeak.
> >VA is also consistent, but #= doesn't match any other Smalltalk varient
> that we've looked at.
> >Squeak, Pharo, Dolphin all currently have the same answer, but are not
> >consistent.
>
> >Interesting indeed.
>
> I have been talking to the VA Smalltalk guys about this and they are
> thinking about it but haven't decided what to do
> yet.  It turns out that the way collections (like Set) that use #hash in
> VA Smalltalk work, because of the #= test
> failing for intervals that cover the same range and have the same hash,
> that it overrides the equal hash value and adds
> the interval to the collection.  I find this troubling.
>
> Lou
>

The rules for = and hash are that if two object are #=, then their hash
values have to be equal as well.

There is no statement about if two objects hashes are the same, what this
means for equality.  This, I believe, is intentional.

The collection objects in (most?all?) smalltalks behave similarly to VA's -
if objects have the same hash but are not equal, then they will both be in
the hashed collection (such as Set).  The squeak implementation is
described in Set>>scanFor: .  This method also shows why having objects
equal but their hash not equal is so dangerous - if you had two objects
that are supposed to be one and the same and are in fact #= but don't have
the same hash, they can both show up in a Set together, or as keys in a
Dictionary together, which breaks what we would expect.

But getting back to VA's collection issue that you have issues with - they
are undoubtedly doing something similar in their collections that we do in
Squeak, which is what is expected (although not necessarily obvious).

A long time ago, I took advantage of this and just hard-coded the hash for
some of my classes to 1. This actually did work, but is a horrible (I mean
HORRIBLE) idea - it really, really slows down the system when you have more
than a couple instances of an object, but it does work.

-cbc


>
>
> >thanks,
> >cbc
> >
> >On Thu, Nov 1, 2018 at 5:40 AM Louis LaBrunda <Lou at keystone-software.com>
> >wrote:
> >
> >> Hi Benoit,
> >>
> >> On the latest version of VA Smalltalk:
> >>
> >> VA Smalltalk V9.1 (32-bit); Image: 9.1 [413]
> >> VM Timestamp: 4.0, 10/01/18 (100)
> >>
> >> I see:
> >>
> >> (0 to: 1) = (0 to: 5/3). "false"
> >> (0 to: 1) hash = (0 to: 5/3) hash. "true"
> >>
> >> Very interesting.
> >>
> >> Lou
> >>
> >>
> >> On Thu, 1 Nov 2018 02:40:00 +0000 (UTC), Benoit St-Jean via Squeak-dev <
> >> squeak-dev at lists.squeakfoundation.org> wrote:
> >>
> >> >Interesting!
> >> >
> >> >As a comparison:
> >> >Squeak 5.2
> >> >(0 to: 1) = (0 to: 5/3). "true"(0 to: 1) hash = (0 to: 5/3) hash.
> "false"
> >> >Dolphin 7(0 to: 1) = (0 to: 5/3). "true"(0 to: 1) hash = (0 to: 5/3)
> >> hash. "false"
> >> >VisualWorks 8.1.1(0 to: 1) = (0 to: 5/3). "true"
> >> >(0 to: 1) hash = (0 to: 5/3) hash. "true"
> >> >Pharo 5.0(0 to: 1) = (0 to: 5/3). "true"
> >> >(0 to: 1) hash = (0 to: 5/3) hash. "false"
> >> >
> >> >I don't have VAST installed on the PC I'm using right now.  I'd be
> >> curious to see how other Smalltalk and/or GemStone handle this?  So far
> >> (according to what I could test, only VW is right (according to the ANSI
> >> standard and just plain logic!)
> >> >
> >> >I wonder how much code relies on this "behavior" out there!
> >> >But the ANSI Smalltalk draft is very clear on this (revision 1.9, page
> >> 53, http://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf
> ):
> >> >"If the value of receiver = comparand is true then the receiver and
> >> comparand *must* have equivalent hash values."
> >> >That's what I always thought (or was taught or even read in the Blue
> >> Book).  Was this something that was changed at some point???
> >> >
> >> >----------------
> >> >BenoƮt St-Jean
> >> >Yahoo! Messenger: bstjean
> >> >Twitter: @BenLeChialeux
> >> >Pinterest: benoitstjean
> >> >Instagram: Chef_Benito
> >> >IRC: lamneth
> >> >Blogue: endormitoire.wordpress.com
> >> >"A standpoint is an intellectual horizon of radius zero".  (A.
> Einstein)
> >> --
> >> Louis LaBrunda
> >> Keystone Software Corp.
> >> SkypeMe callto://PhotonDemon
> >>
> >>
> >>
> --
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181102/2cdaec63/attachment.html>


More information about the Squeak-dev mailing list