Re: [Haskell-cafe] Re: (flawed?) benchmark : sort

On Mon, Mar 10, 2008 at 12:19 PM, Adrian Hey wrote:

Denis Bueno wrote:

...

On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey wrote:

...

...

...

The Eq instance you've given violates the law that (x == y) = True implies x = y. Of course the Haskell standard doesn't specify this law, but it should.

Unless I'm missing something obvious, the example Neil gave earlier should make it clear how impossible this requirement is:

What if I had made the definition of Foo:

data Foo = Foo Int (Int -> Int)

There is no way in general to decide the observational equivalence of two values of this data type (by reduction to the halting problem). Therefore it is impossible to write any function implementing such an equality test.

Did you read my original response to this example?

http://www.haskell.org/pipermail/haskell-cafe/2008-March/040356.html

Yes. You would argue that one should not export the data constructor Foo. That is a decision that requires more details about the code providing Foo, although it certainly seems a reasonable approach in many cases. Supposing I wanted to export Foo, though, the condition you'd like to put on == breaks down. Even if I don't export Foo, how do I ensure that any standard library functions called from the Foo library don't depend on the condition you'd like to put on ==? Do I have to examine them individually? Wouldn't it be easier to reason about code if we constrain the semantics of == as *little* as possible (as an equivalence relation)? -- Denis