Re: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)

On Wed, Aug 20, 2014 at 9:20 PM, Michael Snoyman wrote:

On Wed, Aug 20, 2014 at 12:15 PM, Erik Hesselink wrote:

...

On Wed, Aug 20, 2014 at 10:35 AM, Michael Snoyman wrote:

...

On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell wrote:

...

On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink wrote:

...

As I understood, the question was if GHC would first compare pointers, and only call the Eq instance if the pointers are not equal. I guess this would be safe, but I don't think GHC does such a thing.

I think the reason it isn't done is that it's not always an optimization. We do it manually in e.g. bytestring.

There are two cases I can think of where it would also change the semantics of the code:

1. An Eq instance that doesn't obey the reflective property (not recommended):

data BadEq = BadEq instance Eq BadEq where BadEq == BadEq = False

I think this is just a buggy instance, and if you do this, nothing is guaranteed. Many functions with an Eq constraint will also not work. Interestingly, reflexivity is not a law listed in the haddock documentation.

Erik

I agree that this is terrible practice, and I hope no one is actually doing this. It's unfortunate that reflexivity isn't listed in the Haddocks. Perhaps we should start a separate proposal for making reflexivity an officially required law of the Eq class.

Michael

The problem with requiring reflexivity (or *any* law related to Eq/Ord, for that matter) is that Double and Float break it. Observe: ghci> let nan = 0.0 / 0.0 in nan == nan False Rust[1] side-steps this issue by having separate Eq (lawful) and PartialEq (unlawful) classes, but it's a pretty intrusive change. Chris [1] http://doc.rust-lang.org/core/cmp/trait.PartialEq.html