On Tue, Dec 21, 2010 at 4:30 AM, Jean-Marie Gaillourdet <[email protected]> wrote: > Hi, > > sorry for answering to such an old thread. > > David Menendez <[email protected]> writes: > >> On Fri, Oct 29, 2010 at 8:33 AM, Tillmann Rendel >> <[email protected]> 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 <[email protected]> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
