All of that said, I too find the VA troubling a bit in this case.  I rely
on this (0 to: 1) = (0 to: 5/3) being true.  VA not supporting is limits
cross-dialect portability, although I don't (personally) use VA, other
folks at work do and we do occasionally share code.

However, this implementation is internally consistent and obeys the = and
hash rule in this case.  Its just not what I would want.

-cbc

On Fri, Nov 2, 2018 at 9:52 AM Chris Cunningham <cunningham.cb at gmail.com>
wrote:

> 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/a68c9b38/attachment.html>