polymorphic equality and overloading
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:  20000705 (22:18) 
From:  Pierre Weis <Pierre.Weis@i...> 
Subject:  Re: polymorphic equality and overloading 
> > 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/