Re: polymorphic equality and overloading

[Pierre Weis <Pierre.Weis@inria.fr>]

> > Look at mathematics: equality is polymorphic. Addition is just overloaded.
> 
> But as you know (and as I wrote in my previous messages), the
> polymorphic equality in Caml is not at all the "equality in
> mathematics" for many (or most?) datatypes.

No. As you know (and as I wrote in the Caml FAQ) the polymorphic
equality in Caml is the "equality in mathematics" for many (or most?)
datatypes. A few exceptions are (as in maths)
-- functions, for which mathematical equality needs complex demonstrations
-- quotient types using complex equivalence relations, such as
rational numbers or even reals or complex numbers.

Note that for those values equality is simply undecidable in general.
Note also that polymorphic equality is just pratical and useful, and
not confusing at all if you know something about mathematical entities
involved in the values manipulated by Caml programs. I would not
expect mathematical equality to decide if any two real numbers are
equal or not, since I know this is not decidable. I just would like to
be able to demonstrate the equality of 2 particular real numbers, and
hope the equality to be an extension of equality on simpler numbers,
such as integers or decimal point numbers or even rational numbers,
because I need a valid answer in those simple cases.  Unless for the
rational case, it is exactly what is now the Caml polymorphic
equality; going further to extend equality for rational numbers or
even any other user's defined data type is difficult and a current
research area. In the meantime, current polymorphic equality is the
simplest way of handling semantic equality in a polymorphic language.
Put it another way: polymorphic equality in Caml has some drawbacks,
some of them you should expect, since they are directly burried from
mathematics, few others you have to learn, but it is worth the
(little) effort.

Choosing Haskell for the treatment of equality in the language is just
a kind of misunderstanding of this powerful language and its profund
differences wrt other traditional programming languages. Tell me you
would prefer Haskell's clean lazy semantics, over Caml's strict
interpretation of computation. Tell me also you would prefer monads
and their fascinating categorical origin and propertie, over Caml's
trivial and traditional way of handling loops and sequences and side
effects. Tell me again you hate Caml's oversimplified printf compared
to the so versatile and complex Haskell's make_string. If you tell me
this kind of thing I will be glad to tell you Caml is not for you; I
will just warn you that all this Haskel powerful new stuff is really a
bit confusing for the beginner. But no doubt that if you can pay the
price it is worth the investment. You might also come back to Caml
after a while, just because it handles trivially a lot of useful
features (such as debugging); anyway, you will have learn a lot of
interesting things about programming in using Haskell. May be in the
first place, not to rely too much on polymorphic equality in your
programs, but to define your own complex equivalence relations on your
own complex data types.

All the best for your experiments with modern programming languages

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/