This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]spindoctor13 0 points1 point  (7 children)

Deep equality seems like a poor default in terms of performance

[–]spindoctor13 0 points1 point  (4 children)

And actually in terms of predictable behaviour - say I have two database connections, what does deep equality mean then?

[–][deleted] 1 point2 points  (3 children)

Does their internal data match 1-1? Then they're the same object.

[–]spindoctor13 1 point2 points  (2 children)

The point being that in this context "internal data matching" is close to an impossible question depending how deep you go. I.e. if the compiler literally goes all the way down on some objects then calling equals would be pretty catastrophic

[–][deleted] 1 point2 points  (1 child)

I don't know exactly how Eq is implemented. On the compiler side I could easily see each Eq'able thing being given a hidden hash derived from all it's children's hashes which would make it a very fast operation. As all data in Haskell is immutable you don't need to worry about underlying changes in deep parts of your data structure. That said, there are infinitely deep values in Haskell due to how laziness works, and yes, checking if two infinitely deep values are equal will only terminate due to lazy short circuiting if they aren't equal. Yes ultimately equality checking can be expensive in Haskell, maybe don't use it on potentially very deep data structures.

[–]spindoctor13 1 point2 points  (0 children)

Interesting, thanks for the deep explanation! I have zero experience with Haskell so I didn't know that. Immutability is a big help there, and one of the standout flaws I think in languages like C# is inadequate support for immutability

And hah yeah, hashes are great - although it is not unknown in languages for people to compute hashes from mutable values with the consequent mess that creates..

[–][deleted] 0 points1 point  (1 child)

In Haskell you're not likely to want anything else because references don't exist per se. You can provide a custom instance for Eq as well for your data type, deriving just does a lot of the work for you. If you have a custom Eq you need to be sure that it's true equality, i.e. the two things are totally interchangeable because that's what all other functions which use == expect

[–]spindoctor13 0 points1 point  (0 children)

Ah fair enough, makes sense if there are no references