[Haskell-cafe] type class design

[David Menendez]

On Tue, Dec 21, 2010 at 4:30 AM, Jean-Marie Gaillourdet
<jmg at gaillourdet.net> wrote:
> Hi,
>
> sorry for answering to such an old thread.
>
> David Menendez <dave at zednenem.com> writes:
>
>> On Fri, Oct 29, 2010 at 8:33 AM, Tillmann Rendel
>> <rendel at informatik.uni-marburg.de> wrote:
>>> Hi,
>>>
>>> Uwe Schmidt wrote:
>>>>
>>>> In the standard Haskell classes we can find both cases,
>>>> even within a single class.
>>>>
>>>> Eq with (==) as f and (/=) as g belongs to the 1. case
>>>
>>> Note that the case of (==) and (/=) is slightly different, because not only
>>> can (/=) be defined in terms (==), but also the other way around. The
>>> default definitions of (==) and (/=) are mutually recursive, and trivially
>>> nonterminating. This leaves the choice to the instance writer to either
>>> implement (==) or (/=). Or, for performance reasons, both.
>>
>> While I understand the argument in general, I've never understood why
>> it applies to Eq. Are there any types where it is preferable to define
>> (/=) instead of (==)?
>
> Yes for infinite data structures.

How so?

For an infinite structure, x == y will return False or not return and
x /= y will return True or not return. We still have x /= y = not (x
== y) and I don't see any reason why one would prefer to define (/=)
instead of (==).

-- 
Dave Menendez <dave at zednenem.com>
<http://www.eyrie.org/~zednenem/>