I think Haskell gets it right. All values are immutable. Calling == for two values of some type invokes the Eq implementation for that type, e.g. for strings it

I think Haskell gets it right. All values are immutable. Calling == for two values of some type invokes the Eq implementation for that type, e.g. for strings it's string equality. For the type "IORef a" (box that can contain different a's at different points in time) it compares the identity of the box, not the contents. In fact it can't compare contents, because the type of == stops it from using impure operations like accessing current contents. The same approach could work in imperative or OO languages. For immutable types == should be value equality, while mutable types are analogous to IORef or IOArray, so == should be reference equality. It comes down to observational equality, different instances of the number 2 shouldn't be distinguishable, but different mutable containers with the same contents should be distinguishable because you can make their contents different. I think observational equality is a good fit for pretty much all uses of equality in programming.