[Haskell-cafe] type class design
dave at zednenem.com
Tue Dec 21 18:35:34 CET 2010
On Tue, Dec 21, 2010 at 4:30 AM, Jean-Marie Gaillourdet
<jmg at gaillourdet.net> wrote:
> 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:
>>> 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.
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>
More information about the Haskell-Cafe