-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Update the equals function to fall back to structural equality #154
Conversation
82fb5b2
to
fd43ddc
Compare
I'm looking into what it means, conceptually, to make this same change to |
1ac69a4
to
cc85990
Compare
I prefer this approach over the direction #147 is going. How do you feel about merging this @davidchambers ? |
43bc871
to
13c24c8
Compare
I am happy with the new behaviour. I would like to spend some time reworking the function's description. |
52cbd75
to
299f5c2
Compare
299f5c2
to
2dea6ba
Compare
When comparing two values that are: 1. of the same type; and 2. do not provide a 'fantasy-land/equals'-method; but 3. also don't have a known type with a Z-provided implementation, then previously Z.equals would return false, but this false is just as reliable as a true would be. After this commit, instead of returning false, the Z.equals now returns the structural equality of the two inputs.
In particular, it should always be true for arbitrarily nested structures, where some layers have Setoid and some do not.
92f1ebc
to
4892eda
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for persevering with this!
This PR competes with and so closes #147
When comparing two values that are:
then previously Z.equals would return false, but this false is just as
reliable as a true would be.
After this PR, instead of returning false, the Z.equals now returns
the structural equality of the two inputs.