[Haskell-beginners] (Implicit) equality testing using multiple function definitions

[Brandon Allbery]

On Mon, Jul 18, 2011 at 20:44, Tom Murphy <amindfv at gmail.com> wrote:

> Hi list!
>     When I define an algebraic datatype without an instance for Eq,
> I'm obviously unable to use the (==) function on it. I can
> pattern-match with a series of function definitions (f [] = False; f x
> = True) on the expression, though. Why is that?
>     I understand that in the second case I'm not literally using the
> (==) function, but it seems like there would be instances where you'd
> intentionally not want to be able to test for equality, and
> pattern-matching with multiple function definitions circumvents that.
>

(==) is about value comparison; pattern matching is about constructor
comparison, which is on a higher semantic level as value equality is only
meaningful within the same constructor.

"Circumvents"?  You make it sound like the point of typeclasses is to
restrict things.  In fact, the point is to *undo* the restrictions
necessarily introduced by polymorphism:  if you don't know the type of
something, you don't know what you can do with it.  Typeclasses let us say
"this can be any type, but we need to be able to do <x> with it".  They
don't circumvent; they *add*.

Are you approaching this from an OO perspective, where you can throw
messages at anything and hope they stick?  Haskell, ML, and similar
languages are based on strong types:  if you know the type, you know
*everything* about its possible values.  Dynamic message passing means you
can send a message to an object that doesn't know what to do with it,
producing a runtime error; the whole point of strong typing is to make using
an operation not supported by a given type a *compile time* error.  That is
not to say there aren't hybrid systems (see O'Caml) or static strongly-typed
OO systems (see research papers about OOHaskell; this hasn't been followed
up directly, although it's the basis for a number of other research topics).
 But in general, the design of a Haskell or SML program is in designing
types that reflect the problem space, such that (a) if you do something that
isn't quite right, it is a compile-time error instead of a runtime error,
and (b) the types of functions are themselves the solutions to the problems
(that is, you would like the implementation for some function to be obvious
from its type; when it isn't, this usually means some kind of dependent
typing is going on, which Haskell can't express directly, or that you
otherwise haven't actually captured the problem space with your types).

-- 
brandon s allbery                                      allbery.b at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20110718/1aa1e521/attachment.htm>