-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Will anything break if Hashable got Eq as a superclass? #318
Comments
It's hard to imagine one applicable to hashing-based data structures. For one that isn't, maybe something like computable reals? |
You mean that they cannot be |
Depends on your requirements. Obviously if your numbers are all the same
out to N places then you'll get a lot of collisions.
…On Mon, Aug 30, 2021, 5:05 AM Oleg Grenrus ***@***.***> wrote:
computable reals
You mean that they cannot be Eqd? But can they be hashed either?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOOF7IAIEEADFMVZPSRCELT7NCXJANCNFSM5DBNILHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I think you're asking a very good question, and your suggestion may well be
a good idea.
…On Mon, Aug 30, 2021, 4:57 AM Oleg Grenrus ***@***.***> wrote:
Hashable and Eq have to be compatible for unordered-containers to work
properly, so having Eq as superclass of Hashable seems natural to me.
My question: is there any non-contrived use case for Hashable which will
be ruled out by having Eq superclass? Bonus points if that use case is in
realm of hashing-based data structures, because "This class (Hashable)
exists for the benefit of hashing-based data structures."
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#318>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOOF7M7H5EUWB377OGYHI3T7NBZNANCNFSM5DBNILHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
But what that hash would be useful for? Specifically what algorithm (polymorphic in |
It was pure speculation. I know of none.
…On Mon, Aug 30, 2021, 5:13 AM Oleg Grenrus ***@***.***> wrote:
But what that hash would be useful for? Specifically what algorithm
(polymorphic in Hashable type) would be applicable to this (because if
it's not polymorhic, you don't need to use Hashable).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOOF7OTNMRSMKWZS3TXVALT7NDSPANCNFSM5DBNILHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
https://hackage.haskell.org/package/hashable-1.4.0.0 is on Hackage. If the bounds are simply relaxed to allow However another alternative or additional option is to make a new release with |
I was imprecise, wigh GHC-7:
as I'd suggest just dropping GHC-7 support. It's the simplest option. |
Dropping support for GHC < 8 sounds good to me. If it turns out that some users really need continued support for GHC-7, we can consider a more complex solution. |
I'm missing something. What's the purpose of this change? And how does an |
analogously Eq1 is a superclass of Hashable1. The proposed change is just restrict the |
Alternatives are:
|
I've started working on removing the compat code for GHC < 8. So far, this looks like a very nice cleanup. We can even get rid of an entire module: https://github.com/haskell-unordered-containers/unordered-containers/blob/master/Data/HashMap/Internal/Unsafe.hs |
I'm not using 7.x anymore. If y'all think other people won't mind, let's go ahead. |
And getting rid of hideously dangerous code is always good. |
This prepares u-c for supporting hashable-1.4, as discussed in #318.
This prepares u-c for supporting hashable-1.4, as discussed in #318.
Is there an ETA for a release? |
Hashable
andEq
have to be compatible forunordered-containers
to work properly, so havingEq
as superclass ofHashable
seems natural to me.My question: is there any non-contrived use case for
Hashable
which will be ruled out by havingEq
superclass? Bonus points if that use case is in realm of hashing-based data structures, because "This class (Hashable
) exists for the benefit of hashing-based data structures."EDIT: I'm asking here first, for smaller audience. Will later ask on libraries list & other fora.
The text was updated successfully, but these errors were encountered: